Open Stack

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.
For a project using PBR postversioning (almost all by now) this can be
achieved by either pushing the appropriate alpha git tag or by using
PBR Sem-Ver: feature https://docs.openstack.org/developer/pbr/#version
Now, purists would complain that artificial commit right after
branching is not really adding a feature but you could look at it as a
credit because you surely will implement new features in the new
version!
If project is without stable:follows-policy tag and it will keep
adding features on the stable branch, increasing Y part of semver or
if they already decided to bump X major version, Sem-Ver: api-break
can be used.
Example for TripleO projects for opening Ocata:
https://review.openstack.org/#/q/topic:open-ocata+Sem-Ver:

> As reference, puppet team proposed a solution for this issue in
> openstack puppet modules in
> http://lists.openstack.org/pipermail/openstack-dev/2017-March/113494.html
>
> However, as mentioned before this is affecting all projects, not only
> puppet ones.

Solution for OpenStack Puppet modules is to explicitly set pre-version
in metadata.json.
We had used pre-versioning before in regular OpenStack projects by
setting version in setup.cfg but this has been abandoned and instead
we rely on PBR to compute the next version.

>> I know we don't expect to fully support upgrades to pre-milestone releases,
>> but the requirement here is to simply enable testing them.
>>
>> A side-benefit of this regular testing e.g via CI is we'll find upgrade issues
>> much faster than waiting for one or more milestone releases to happen then
>> doing an upgrade-debug firedrill later in the cycle (which has been bad for
>> project and deployment teams IMO, so it'd be good to figure out this first
>> step to enable earlier testing of upgrades to the development release).
>>
>> Any thoughts on how we can resolve this would be much appreciated, thanks!

I was suggested that upgrade jobs could force install i.e. basically
doing downgrades before milestone1 but that's not testing upgrades!
Versioning is very fundamental for packaging and reflects upstream
version, we cannot fake versions in packaging.
In the spirit of Continuous Everything, versioning should also be
continuous and ensured that master version is always > previous
releases.
Projects doing stable branches could take action individually using
Sem-Ver keyword but better would be to define this as a rule for
having stable branches and enforce it cross projects by the release
procedure.

Cheers,
Alan