Open Stack

On Mon, Aug 3, 2015, at 05:46 AM, Thierry Carrez wrote:
> Hi everyone,
> 
> A month ago the stable branch team decided to move away from
> synchronized stable point releases and enable continuous stable branch
> delivery instead.
> 
> The end goal is that every commit on a stable branch for a "service"
> project will get a .Z version increment, and a tag be pushed to match.
> So we'll have for example Nova 12.0.0 at Liberty release, and each
> stable branch commit will result in 12.0.1, 12.0.2... versions.
> 
> In order to make this work, it looks like we'd require:
> 
> * pbr changes so that it supports a mode where every commit on the
> branch increments .Z
> 
> * infra changes to automatically push the corresponding tag when the
> commit is merged
> 
> To give you an idea, if we enabled that for Kilo we'd be at Nova 11.0.80
> (kilo) and Nova 10.0.218 (juno).
I am not a fan of doing this second option at all. We would be polluting
the ref space of our repos with redundant information making the output
of `git tag` unusable to humans. If this was not redundant info and a
tag of 11.0.80 provided more information than a generated version of
11.0.0.dev80 / 11.0.80 I think we could live with that, but it does not.

I am told one piece of additional info in a tag that may be desirable
here is GPG signing of sources for artifacts. Git does support GPG
signed commits and not just tags if you have a non ancient version of
git. Mtreinish reports thats this works well with our Gerrit server.
Though we would possibly need richer ACL support in Gerrit to require
stable branch commits be signed.

My preference would be to stick with the existing PBR versioning for
simplicity, though I am fine with updating PBR to treat commits as
proper point releases as that is a better reflection of reality. Then we
can work on using signed commits if that helps downstreams.
> 
> We'd need to enable those changes after final release for
> stable/liberty, which means we'd need to get the tooling right before
> October 15.
> 
> If we can't figure out a way to make this work (or we decide it was
> actually insane), the backup plan is to move to each project releasing
> stable branch versions from time to time by manually requesting a
> 12.0.1, 12.0.2... tag when they feel like it. The benefit of this
> approach is that it matches what we do for libraries. The drawback is
> that it requires project teams to pay more attention to stable branches.
I wonder why that is a drawback? I am not heavily involved in stable
branch support but it seems like this is a reasonable expectation to
have of projects and would result in better stable releases overall?
This backup plan seems reasonable enough to be considered as a first
plan option too.

Clark