[Starlingx-discuss] Flock Versioning for packaging
sgw at linux.intel.com
Wed May 15 18:28:53 UTC 2019
Currently the versioning of the flock is mostly matching their internal
API '1.0-<tis_patch_ver>.tis'. This is historical since the Upgrade
process is a complete re-image of the disk from ISO and doesn't actually
have to increase the version number between releases (other than maybe
Moving forward we need to consider using the OpenStack Semantic
Versioning , and looking at PBR (Python Build Reasonableness)  to
generate the version that is based on MAJOR.MINOR.PATCH where:
- MAJOR version when you make incompatible API changes
- MINOR version when you add functionality in a backwards-compatible manner
- PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as
extensions to the MAJOR.MINOR.PATCH format.
We understand the requirement that the Flock has across releases to
preserve backward compatibility, likely the MAJOR will never change, but
we should be considering that we bump the MINOR on each release and
reset PATCH and bump PATCH based on doing a CVE, or required bug fix
To enable PBR, we would need to change the Python related setup to use
setup.cfg with pbr, some of this work has started by Dean with Devstack
related work. PBR won't address all packages since some are non-Python.
We would also have to add versoining tags into git for PBR to work
correctly. PBR can also help generate information for packaging.
During development, X.Y.Z.dev<N> or a "+g<hash>" is possible for builds.
This is needed to during the development phase in order to track changes
and help debug failures based on what packages are installed, it could
also allow for independently updating of packages on a target system
using standard packaging tools. This will be particularly important if
we install flock packages on a standard OS and not via a custom ISO.
or PBR to work.
For example we are currently at fm-common-1.0-8.tis or
sysinv-1.0-317.tis (for the master) as we approach the "stx-2.0" release
for each commit to stx-fault a tarball would be generated:
fm-common-1.0.0.dev<X> ... fm-common-1.0.0.dev<X+1>. When we release
stx-2.0 the release tarball will be fm-common-1.2.0 and a patch will be
fm-common-1.2.1. As we start the next release work will happen on
OpenDev has the infrastructure already via Zuul to generate and publish
both release and intermediate development artifacts. We will need to
make some policy decisions regarding how long we keep devlopment artifacts.
The justification for these changes are to ensure versioning that will
work correctly for the various build tools of the different operating
systems that maybe required for StarlingX to exist on. Every operating
system has its own build recipe format to create packages to distribute
the SW project across their users. Each package includes metadata that
describes the package’s components, version, release, build and
installation instructions among others. Without a proper version from
the original source code , the distributions will have a hard time
managing the packaging.
Please comment, this is a strawman to get input, after that the next
step is to generate a proper Specification.
More information about the Starlingx-discuss