This documents explains the packaging procedures and naming conventions for the networking-midonet MidoNet's Neutron plugin.
Following the guides, they strongly recommend to name the package after the
upstream source code. Since the source code has needed to change to
networking-midonet due StackForge naming conventions, I propose to rename
the package to python-networking-midonet since Kilo.
networking-midonet is a Neutron plugin that keeps being updated even there are
not more Neutron maintaining releases: either by adding fixes to the plugin, or
by adding extensions, or support for new MidoNet features. So, the version number
should contain the version of Neutron that's compatible with and its own version
number. Version tag has 3 sections:
XXXX.N.P
Where:
- XXXX.N is the Neutron's version release naming
- P is the plugin's patch release.
noarch for Fedora and all for Debian. That's all. This package is architecture independent.
We will support rpm, deb and source tarballs.
We discuss here the minimal details that could make differences between three
supported packaging formats: tarball, rpm and deb.
Pypi accepted version number is based on PEP440 specification. In short: no letters, no release numbers and only some devX values for pre releases and postX for post-releases.
Of course, as a difference to other packaging systems, naming conventions does not force us to add the python suffix.
So we plan to upload to pypi only when there are new releases of our plugin. Tarball format is:
networking-midonet-XXXX.N.P.tar.gz
For rpm packages we have based on the Fedora's Packaging Guidelines.
The release tag will be:
- 0.0. for nightly builds
- 0.1.rc%{Y} for release candidates. the words
rcshould always have more precedence that any snapshot in packaging managers, so the 0.0 and 0.1 release value may not be necessary, but I like to keep it to maintain consistency with current MidoNet's packaging guidelines. %{Y} is the rc value. - 1 for new releases.
Release tag will be inserted by the packaging system jobs (such as Jenkins, Koji or whatever)
All the packages will be built over they target architecture. No fpm any more. Jenkins jobs will provide the Docker containers to build those packages.
According to Fedora's documentation:
%{checkout} consists of the date that the snapshot is made in YYYYMMDD
format, a short (2-5 characters) string identifying the type of revision
control system or that this is a snapshot, and optionally, up to 13
characters (ASCII) alphanumeric characters that could be useful in finding
the revision in the revision control system
showing these examples:
20110102snap
20110102git
20110102git9e88d7e
I would propose the third one, which makes the difference between two packages that are build the same day.
Fedora allows a, b, alpha, beta or rc as non-numeric values in pre-releases. We will only use the rc ones in packaging.
I would not use post-release packages: we have already the minor release number in our version to indicate bug fixes over a released versions.
Examples of rpm-based packages would be:
- Nightly build of plugin compatible with current Kilo (2015.1) development:
python-networking-midonet-2015.1.0-0.0.20150434git238ab24.noarch.rpm
- Release candidate number 4 of the plugin second patch release,
python-networking-midonet-2015.1.2-0.1.rc4.noarch.rpm
- Bugfix release of the plugin compatible with Liberty (2015.2)
python-networking-midonet-2015.2.1-1.noarch.rpm
For deb package we have based on the How to package for Debian site.
Debian packaging follows the same format:
[epoch:]upstream_version[-debian_revision]
Where neither epoch and +debian_revision are mandatory. We don't need to
define an epoch and, according to the documentation, the debian_revison:
It is optional; if it isn't present then the upstream_version may not
contain a hyphen. This format represents the case where a piece of software
was written specifically to be a Debian package, where the Debian package
source must always be identical to the pristine source and therefore no
revision indication is required.
We will use the same source code, so debian_revision is not needed too. When
it comes to upstream_version sort order:
First the initial part of each string consisting entirely of non-digit
characters is determined. These two parts (one of which may be empty) are
compared lexically. If a difference is found it is returned. The lexical
comparison is a comparison of ASCII values modified so that all the letters
sort earlier than all the non-letters and so that a tilde sorts before
anything, even the end of a part.
So we will leverage the tilde (~) to define the snapshots and any rc value
will be ordered before any number.
Debian does not specify any snapshot value, so we will use the same one as Fedora but with the tilde: ~YYYYMMDDgit like this
~20110102git9e88d7e
Again, there is no format definition for pre-releases. Using rc like Fedora and knowing that they will be sorted after any ~ snapshot will guarantee us coherency.
No post-release definition and no need for it.
Giving the same examples as for Fedora packages:
- Nightly build of plugin compatible with current Kilo (2015.1) development:
python-networking-midonet-2015.1.0~20150434git238ab24_all.deb
- Release candidate number 4 of the plugin second patch release (new features)
python-networking-midonet-2015.1.2~rc4_all.deb
- Bugfix release of the plugin compatible with Liberty (2015.2)
python-networking-midonet-2015.2.1_all.rpm