Old versioning scheme does not represents proper meta-data for deb packages. For rpm packages we have agreed scheme (separate-mos-from-centos) wich is representing proper meta-data at package suffix part and know deb packages need to be renamed with the account of specific of distribution.
Need to introduce into CI/Build new naming and version policy for deb packages instead of using elaborated previously old scheme.
Package version string, as well as package metadata for a MOS specific or divergent package must not include registered trademarks of base distro vendors, and should include “mos” keyword.
Package name constructs from:
<name>-<version><deb-revision>~<base-distro-release>+mos<subversion>
For example:
python-nova-12.0.0-1~u14.04+mos5
Where:
python-nova - name
12.0.0 - code version
1 - debian package revision
u14.04 - base Linux distribution
5 - <subversion>
Where:
At present moment MOS subversion part represented as amount of commits into code and build projects since brach was created.
Version in changelog file should be modified by CI/Build:
CI/Build system should modify deb changelog value before build process to ensure that package version and release represents truth:
Example:
was: nova (2:12.0.0-1~u14.04+mos823) mos8.0; urgency=medium
became: nova (2:12.0.0-1~u14.04+mos5) mos8.0; urgency=medium
This modification leads to transformations as follows:
python-nova-12.0.0-1~u14.04+mos823 -> python-nova-12.0.0-1~u14.04+mos5
Subversion:
This number represents amount of commits into code since last tag change in current code branch and must be added after mos.
Example:
python-nova-12.0.0-1~u14.04+mos5 -> python-nova-12.0.0-1~u14.04+mos6
Structure of Subversion for packages maintained by Mirantis:
python-nova-12.0.0-1~u14.04+mos5 Where:
For example we have python-nova package with code version = 12.0.0
Only packages from security repository should have security update bundle number at the very end!
Regular packages should only have commits number for the very last value in version string.
The name and the upstream version of a package backported from external sources (Debian unstable, newer Ubuntu releases, etc) should be kept intact. ~${target_distro}+mos${subversion} suffix should be appended to the package revision. No other changes of the package revision is allowed, except removing trademarks (and other modifications required for a legal redistribution of the package). Initially the subversion is set to 1 and is bumped on every modification based on the same original version of the package.
Example:
Initial import:
python-zzzeeksphinx_1.0.17-1 -> python-zzzeeksphinx_1.0.17-1~u14.04+mos1
Update based on the same original version:
python-zzzeeksphinx_1.0.17-1~u14.04+mos1 ->
python-zzzeeksphinx_1.0.17-1~u14.04+mos2
Sync with the original distro (say, Debian unstable):
python-zzzeeksphinx_1.0.17-2 -> python-zzzeeksphinx_1.0.17-2~u14.04+mos1
Backporting to the stable (GA) MOS branches should be done according to the scheme described at post-release updates.
If required to update package build manifests (debian/ folder) or add patch or make any other modifications not related to code version update, debian package revision number must be increased. If a major change (new version of the software being packaged) occurs, the version number is changed to reflect the new software version, and debian package release number is reset to 1. In case of packages maintained by MOS this is valid for OpenStack projects.
For non OpenStack projects, like dependencies and back-ported packages all updates will be represented in commits number part of release. After code version update Commits number value resets to 1 and will be increased in cases of further modifications of a package.
Update of dependencies within one code version(non OpenStack):
python-zzzeeksphinx_1.0.17-1~u14.04+mos1 ->
python-zzzeeksphinx_1.0.17-1~u14.04+mos2
Update of dependencies in case of code version update(non OpenStack):
python-zzzeeksphinx_1.0.17-1~u14.04+mos2 ->
python-zzzeeksphinx_1.0.19-1~u14.04+mos1
Update of OpenStack project - debian/ changed:
python-nova-12.0.0-1~u14.04+mos5 -> python-nova-12.0.0-2~u14.04+mos5
Update of OpenStack project - code tag/branch changed:
python-nova-12.0.0-2~u14.04+mos5 -> python-nova-13.0.0-1~u14.04+mos0
In case of binary package upgrades within same Linux distribution version in future, changes introduced here, will make us able to get next benefits:
Example:
mosX: mysql-server-wsrep-5.6-5.6.23-1~u14.04+mos2
mosY: mysql-server-wsrep-5.6-5.6.23-1~u14.04+mos2
In case of switching to next version of Linux distribution as base layer without additional changes in project code <base-distro-release> must be changed.
Example:
Ubuntu 14.04: mysql-server-wsrep-5.6-5.6.23-1~u14.04+mos2
Ubuntu 16.04: mysql-server-wsrep-5.6-5.6.23-1~u16.04+mos2
Updates:
Since MOS reaches GA status, ie officially released, all updated packages will be published into separate updates repository. A suffix containing the GA release number and a second counter which tracks the updates within the stable/GA release must be added (in order to avoid version clashes with the same package in a development branch of MOS). Also changes made in updates within same code version should be proposed into master branch to keep packages in consistent state:
{revision at freeze}+r{mos major release number}+{update counter}
Non-OpenStack projects:
First update:
python-zzzeeksphinx_1.0.17-1~u14.04+mos20 ->
python-zzzeeksphinx_1.0.17-1~u14.04+mos20+r8+1
2nd update:
python-zzzeeksphinx_1.0.17-1~u14.04+mos20+r8+1 ->
python-zzzeeksphinx_1.0.17-1~u14.04+mos20+r8+2
OpenStack projects will continue use incremental approach:
python-nova-12.0.0-1~u14.04+mos15 -> python-nova-12.0.0-1~u14.04+mos16
Security updates:
Security updates will also be published in a separate repository and based on package from updates repository. Additional subsequent digit will be added to the version of a package which represents security bundle number.
Example:
python-zzzeeksphinx_1.0.17-1~u14.04+mos20+r8+1 ->
python-zzzeeksphinx_1.0.17-1~u14.04+mos20+r8+1.1
python-nova-12.0.0-1~u14.04+mos16 -> python-nova-12.0.0-1~u14.04+mos16.1
None
None
None
None
None
None
None
None
None
None
None
None
None
ToDO