Continuous revision number

[enykeev]

During another task it suddenly occurred to me that we can noticeably simplify package deployment and avoid revision number collision and desynchronization if, instead of sequential revision number, we start using CircleCI build number.

[enykeev]

There is no particular need to fix it now and there might be some unforeseen consequences of that, but using build number as revision certainly makes sense to me, could potentially simplify some debug scenarios and even play part in new CI effort.

[arm4b]

deb/rpm packaging should follow the incremental build numbers. From the policy:

release is the number of times this version of the software has been packaged.

Every new version should start with consistent 1 revision/release number. I would follow deb/rpm best practices and recommendations.

While this looks like cool hack, please, let's not do this like bros :)

[enykeev]

It is conventional to restart the debian_revision at 1 each time the upstream_version is increased.

We don't really follow this convention strictly during package promotion though. If the package with revision 1 will fail the test, it would never get promoted to unstable repo and the next revision number would be determined based on latest unstable-staging revision number.

As with any other convention, we are the one who decides how rigorously we want to follow it. I'm personally still thinking it would be highly beneficial for us to have continuous numbering scheme matching ever increasing build number, but feel free to close the PR if team disagrees.

I've opened #395 and #396 for us to keep an eye on the problems with revision number we're currently having.