Release Cycle Observations
So would a longer release cycle help or hurt that? Would having two trains
make it better or worse?
Just want to make things clear that I am only curious and wanted to share
what I see.
On Thu, Sep 26, 2019 at 12:17 PM Ben Nemec <openstack at nemebean.com> wrote:
> On 9/26/19 9:42 AM, Matt Riedemann wrote:
> > In last week's nova meeting we also talked about some of this . If
> > you change the release cycle to do major and minor versions, that's
> > going to be pretty complicated for testing upgrades, because grenade
> > goes from major to major based on branches. We could probably make it
> > work (and maybe it's already possible, I don't know to go from tag
> > (minor release) to master, but the point is you're going to blow up the
> > upgrade test matrix and it's not clear anyone is even going to be
> > consuming those minor intermediate releases. I think this is partly why
> > the release team stopped doing a cycle-with-milestone  release
> > because no one was consuming the milestone releases.
> We've even found that since we started supporting FFU between certain
> releases that many customers won't touch the intervening releases, even
> with six months between them. They're basically on a year-and-a-half
> cycle. This actually makes things worse for the FFU releases because
> having a feature miss one means waiting that much longer for it to show
> up (or we have to carry downstream backports, which sucks).
> I know we'd like to have everyone CD'ing master, but for the foreseeable
> future I think it's more likely that we're going to have a non-trivial
> number of deployers who stick to the longest release cycle that can be
> supported, and that's going to create added pressure during feature
> freeze for whatever that release is.
-------------- next part --------------
An HTML attachment was scrubbed...