Open Stack

Excerpts from Zane Bitter's message of 2018-06-12 17:52:24 -0400:
> On 12/06/18 11:41, Michael Johnson wrote:
> > I think we should continue with option 1.
> > 
> > It is an indicator that a project is active in OpenStack and is
> > explicit about which code should be used together.
> > 
> > Both of those statements hold no technical water, but address the
> > "human" factor of "What is OpenStack?", "What do I need to deploy?",
> > "What is an active project and what is not?", and "How do we advertise
> > what OpenStack can provide?".
> 
> There's a strong argument that that makes sense for services. Although 
> in practice I'm doubtful that very many services could get through a 
> whole cycle without _any_ patches and still be working at the end of it. 
> (Incidentally, does the release tooling check that the gate still passes 
> at the time of release, even if it has been months since the last patch 
> merged?)
> 
> It's not clear that it still makes sense for libraries though, and in 
> practice that's what this process will mostly apply to. (I tend to agree 
> with others in favouring 2, although the release numbering required to 
> account for possible future backports does leave something to be desired.)
> 
> >>> One caveat with this model is that we need to be careful with version
> >>> numbers. Imagine a library that did a 1.18.0 release for queens (which
> >>> stable/queens is created from). Nothing happens in Rocky, so we create
> >>> stable/rocky from the same 1.18.0 release. Same in Stein, so we create
> >>> stable/stein from the same 1.18.0 release. During the Telluride[1] cycle
> >>> some patches land and we want to release that. In order to leave room
> >>> for rocky and stein point releases, we need to skip 1.18.1 and 1.19.0,
> >>> and go directly to 1.20.0. I think we can build release checks to ensure
> >>> that, but that's something to keep in mind.
> 
> Would another option be to release T as 1.19.0 and use 1.18.1.0 and 
> 1.18.2.0 for stable/rocky and stable/stein, respectively? There's no 
> *law* that says version numbers can only have 3 components, right? ;)

We have interpreted PEP 440 and SemVer together to mean that regular
versions have 3 parts and pre-release versions have a 4th part.
That's up for debate, but my counter argument to changing it is
that it will require quite a bit of tooling changes to support
something other than what we have today, and I think it's going to
be easier to build the thing that verifies we're using the right
version numbers by counting stable branches. We have to do that
verification anyway, so we might as well just do it for 3 part version
numbers.

Doug