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.3dev-23-g1234567`
in this example the tag name used is `vyos/1.3.0`
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.3dev`, `1.4dev` 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.4dev-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.4dev` 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>`
to implemenent this the following needs to be done:
* Add a vyos/1.3dev 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.