Open Stack

Excerpts from Thierry Carrez's message of 2017-03-13 15:13:18 +0100:
> Jeremy Stanley wrote:
> > On 2017-03-09 12:12:01 +0100 (+0100), Alan Pevec wrote:
> >> 2017-03-09 10:41 GMT+01:00 Alfredo Moralejo Alonso <amoralej at redhat.com>:
> >>> On Wed, Mar 8, 2017 at 12:44 PM, Steven Hardy <shardy at redhat.com> wrote:
> >>>> https://bugs.launchpad.net/tripleo/+bug/1669462
> >>>>
> >>>> I'm not clear on the best path forward at this point, but the simplest one
> >>>> suggested so far is to simply tag a new pre-milestone/alpha release for all
> >>>> master branches, which will enable testing upgrades to master.
> >>
> >> That would be indeed simplest and cleanest solution but it has been
> >> rejected in the past, IIUC with reasoning that projects are not sure
> >> what will be their next version. IMHO that should not be the case if

There is the problem that some deliverables don't know their next
version in advance. There is also the problem that the vast majority
of our deliverables do not use pre-release versions (like alphas)
at all.

> >> the project has decided to have a stable branch and follows semver and
> >> stable branch policy: in that case project will keep X.Y frozen on
> >> stable so master should be bumped to at least X.Y+1 immediately after
> >> branching stable.
> > [...]
> > 
> > In the past we addressed this by automatically merging the release
> > tag back into master, but we stopped doing that a cycle ago because
> > it complicated release note generation.
> 
> Right, there is a bit of history here.
> 
> One option is to tag the first commit on master after the stable branch
> point, to reduce (but not eliminate) the window where stable > master,
> but that relied on a lot of discipline and checks (since it's hard to
> automate).

Yes, I think the level of coordination involved in making this work for
all projects would be challenging to accomplish with the small release
team. We have the release task list down to a fairly small minimum right
now, and I don't relish the idea of adding more complexity if we can
avoid it.

> We preferred the option to merge tags back on master, which was not
> perfect (creates overlap in versions automatically generated) but at
> least the dev version was always > last released version.
> 
> However, the merged tags history prevented reno from determining
> correctly where it was and generate appropriate release notes. So we

The problem was with a tag appearing on multiple branches, and basically
being inserted into the master branch at a random spot, it wasn't
possible to actually tell which series a version belonged to and which
notes should go with which versions.

> dropped it... Robert Collins argued that users should consume from a
> single channel anyway: either follow master or follow a stable branch,
> and not combine both. Here the problem is that you test upgrades from
> stable/$foo to master, which is basically something the model does not
> support.

We test this upgrade scenario in the upstream CI, too. The difference
is that grenade can tell pip "install exactly the version I am
pointing to in this directory on disk," rather than relying on
version numbers to notice that an upgrade is needed (or should be
avoided, as the case may be).

Is it possible to do that with system packages in some way, too, without
pinning package versions in puppet or tripleo?

Doug