Experimental Physics and
that is a very good question as while there is some practice in that regard, there are cases every now and then when things are done in a different manner which then cause more things to be done in a different manner.
With versions, we want to consider:
- Upstream version (increased with new upstream)
- Debian revision (increased with debianization changes in epicsdeb)
- Debian distribution (depends on the package build target)
- Builder upload (when multiple uploads are performed for our builder for whatever reason, version must increase)
Upstream version and Debian revision numbers are derived from epicsdeb. On top of that, we optionally add other two. Currently for the new repository setup, everything is built for jessie as following:
If the package is not native, it is <upstream>-<revision>.<upload>, e.g. devlib2 is 2.8-1.1.
If the package is native, it is <upstream>+nmu<upload>, e.g. epics-debhelper is 8.17+nmu1.
There is no distribution specification as if jessie is "implicitly" considered to be "baseline". Now, when building for stretch, we should make sure that versions there are "greater" to ensure proper package update... Thus, it's better to have all aforementioned numbers included in the version. The proposed format for packages built from now on is:
For not native packages: <upstream>-<revision>+<distribution>u<upload>, e.g. new devlib2 build would be 2.8-1+deb9u1
For native packages: <upstream>+<distribution>+nmu<upload>, e.g. new epics-debhelper build would be 8.17+deb9+nmu1
I presume it will enable consistent version advancement in all four categories. System upgrades and backports/fixes are not something which we have happening terribly often, but if they do...
Any comments on the matter are welcome.
On Mon, Apr 23, 2018 at 5:37 AM, Christoph Schroeder <firstname.lastname@example.org> wrote:
|ANJ, 26 Apr 2018||
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·