[Starlingx-discuss] Flock Versioning for packaging

[Dean Troyer]

On Wed, May 15, 2019 at 1:29 PM Saul Wold <sgw at linux.intel.com> wrote:
> Moving forward we need to consider using the OpenStack Semantic
> Versioning [0], and looking at PBR (Python Build Reasonableness) [1] 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
> between releases.

One thing to consider with regards to OpenStack versioning is that
each project is versioned independently and the major version is
increased at the integrated release at the end of the dev cycle.
Also, sub-components are often completely independently versioned from
the rest of the project (see neutron and neutron-lib for an example of
this) and the major version is not automatically incremented.

For a variety of reasons (admittedly familiarity is big here) I want
to move toward that kind of system.  Unless there is great support for
just jumping toward the full setup I think we can start incrementally
by independently versioning the major components, which may involve
splitting some things out of their existing home.

The part that I have the most personal interest in is splitting out
the client and library (dependency) components and using a release
model similar to OpenStack's cycle-with-intermediary[0].  This is what
I have used for OpenStackClient and osc-lib and it lets us a) release
as necessary for bug fixes, and b) still have a checkpoint that is
known to be co-installable with the coordinated cycle release.

dt

[0] https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary

--
Dean Troyer
dtroyer at gmail.com