Open Stack

Clark Boylan wrote:
> On Mon, Aug 3, 2015, at 05:46 AM, Thierry Carrez wrote:
>> 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 tend to agree that pushing a tag per commit would end up being very
noisy. I think the main problem we are trying to solve is to be able to
map version numbers to git commits. A security fix might be introduced
at 11.0.73 so being able to see that whatever you get is "past that" is
useful.

There are two ways of avoiding massive tag pollution: not using tags to
solve the above problem (but lifeless said it was the only sensible
route), or doing on-demand tagging rather than automatic tagging.

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

So the trick here is that you still want them frequently released, so
that they can serve as reference points. That means every month or so,
someone in a project team will need to care. I'm not saying it would be
a bad thing, I'm just saying that in the past, nobody had to care. So
with this option, the release liaison role (often currently served, by
default, by the PTL) gets busier.

-- 
Thierry Carrez (ttx)