On Wed, May 15, 2019 at 1:29 PM Saul Wold <sgw@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-inte... -- Dean Troyer dtroyer@gmail.com