osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[all][release] One following-cycle release model to bind them all


On Wed, 10 Jun 2020 at 18:06, Jeremy Stanley <fungi at yuggoth.org> wrote:
>
> On 2020-06-10 17:33:55 +0100 (+0100), Mark Goddard wrote:
> [...]
> > I think the issue is that currently there is a period of time in
> > which every project has a release candidate which can be packaged
> > and tested, prior to the release. In the new model there is no
> > obligation to release anything prior to GA, and I expect most
> > teams would not.
>
> You and I clearly read very different proposals then.

Friendlier wording: we interpreted it differently.

> My
> understanding is that this does not get rid of the period of time
> you're describing, just changes the tags we use in it:
>
> [Excerpt from Thierry's original post yesterday...]
>
> > > The "final" release would be marked by creating a release
> > > (stable) branch, and that would need to be done before a
> > > deadline. Like today, that deadline depends on whether that
> > > deliverable is a library, a client library, a release-trailing
> > > exception or just a regular part of the common release.
> > >
> > > The main change this proposal introduces would be to stop having
> > > release candidates at the end of the cycle. Instead we would
> > > produce a release, which would be a candidate for inclusion in
> > > the coordinated OpenStack release.
>
> For service projects, that "deadline" he talks about would be the
> start of the traditional RC period, we just wouldn't use special rc1
> tags for branching at that point, we'd use actual version numbers to
> branch from. I think the proposal has probably confused some folks
> by saying, "stop having release candidates [...and instead have a]
> candidate for inclusion in the coordinated OpenStack release." It
> would basically still be a "release candidate" in spirit, just not
> in name, and not using the same tagging scheme as we have
> traditionally used for release candidates of service projects.

I think this is reading between the lines somewhat. I agree that it
makes sense however, and preserves the period before release during
which every deliverable to be included in GA should have a release
available.

> --
> Jeremy Stanley