[openstack-dev] [TripleO][release][deployment] Packaging problems due to branch/release ordering

Thierry Carrez thierry at openstack.org
Mon Mar 13 14:13:18 UTC 2017


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
>> 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).

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
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.

-- 
Thierry Carrez (ttx)



More information about the OpenStack-dev mailing list