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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
