Currently when packages are updated, the package version number is not incremented.
That means that two ISO's released 10days apart will have could have the same version number of the package, but the package could have changed multiple times in the same timeframe. and so the package.
To make it more clear for the user (and devs) we need to increment the version number of the package for every commit done, and also show the commit id of the checked-out commit on build-time. we also need to have a solid version numbering shceme that follows the debian versioning scheme.
Generating version numbers based on git tags are quite easy to do, and can be automated when generating the package by adding this to debian/rules of the package:
override_dh_gencontrol:
dh_gencontrol -- -v$(shell (git describe --tags --long --match 'vyos/*' --dirty || echo 0.0-no.git.tag) | sed -E -n 's%vyos/%%p')This will give the vyos version tag as a version prepended by number of commits since the tag and the git current commit id in this format:
<tag>-<commits since tag>-g<commit id> example: 1.3.0-1-g1234567 and 1.3dev0-23-g1234567
in this example the tag name used is vyos/1.3.0
without the --long parameter the tagged commit will be named with just the tag version number, and will not get -<commits since tag>-g<commit id> appended
when the package is built from a modified source with uncomitted work, the version name will be padded with -dirty
the deb/apt version ordering scheme is not self explained, so i've generated a list of possible version names and ordered them in descending order using python apt_pkg.version_compare:
Original order Sorted order Upstream Version 1.3.2 - 1.3.rolling-23-g1234567 : 1.3.rolling-23 1.3.0 - 1.3.rolling-15-g1234567 : 1.3.rolling-15 1.3.rolling - 1.3.rolling : 1.3.rolling 1.3dev1 - 1.3.dev-15-g1234567 : 1.3.dev-15 1.3 - 1.3.dev-20.g1234567 : 1.3.dev 1.3dev5 - 1.3.dev : 1.3.dev 1.3.30 - 1.3.30 : 1.3.30 1.3.1 - 1.3.25 : 1.3.25 1.3dev-10-g1234567 - 1.3.15dev : 1.3.15dev 1.3.dev - 1.3.15 : 1.3.15 1.3dev2 - 1.3.2 : 1.3.2 1.3dev - 1.3.1 : 1.3.1 1.3.15 - 1.3.0 : 1.3.0 1.3.rolling-23-g1234567 - 1.3rolling : 1.3rolling 1.3.15dev - 1.3dev-10-g1234567 : 1.3dev-10 1.3rolling - 1.3dev5 : 1.3dev5 1.3-dev - 1.3dev2 : 1.3dev2 1.3.rolling-15-g1234567 - 1.3dev1 : 1.3dev1 1.3.25 - 1.3dev : 1.3dev 1.3.dev-15-g1234567 - 1.3-dev : 1.3 1.3.dev-20.g1234567 - 1.3 : 1.3
from this list i'm proposing this naming scheme:
rolling versions will have the version number of the NEXT major version until the point that the release is frozen. at that point it increment to the next version. eg. the current rolling is 1.3 rolling, this version will be until 1.3.0 is released. at that point 1.4 rolling is released and 1.3 does not have a rolling release any more.
To keep the current development version numbers as low as possible the tag for them will be 1.3dev0, 1.4dev0 and so on. please mark there are no special characters between the version and name. this is to keep the version index under the 1.4.0 name of the first 1.4 release. this will make the third commit from initial 1.4dev release's version name to be : 1.4dev0-3-g1234567 the development version id will be helt until the next release, or until a development milestone is reached. at that point the devel version increment with an index. from 1.4dev0 to 1.4dev1
All release versions will have the same tree octet layout as found in 1.1.x and 1.2.x releases. the first 1.3 release will be named 1.3.0 and the complete package name for that version will be 1.3.0-0-g1234567 as described before, the forth part of the version number will increment once for every commit, so that will increment until version 1.3.1 is released and the counter is reset to zero.
when a package is unchanged between two major versions, it is good to add an commit to increment the targeted vyos version info for the package , and then we also have a commit to attach the version tag
the full version syntax for all releases will then be <major version>(.<minor version>|dev<dev-index>)[-<commits from tag>-g<git hash>][-dirty]
to implemenent this the following needs to be done:
- Decide if the tagged version should have a short or long version name
- Add a vyos/1.3dev0 tag on all internal packages (needs to be done directly on the repository)
- add code to debian/rules in package(can be added via PR)
This is not taken into effect for now, so this is still open for discussion.