Open Stack

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? ;)

cheers,
Zane.