Open Stack

Hopefully it's somewhat obvious to folks that altering the PBR version 
schema (yet again), breaks *all the people* from using it in a reliable 
manner, and if the goal of PBR is to bring reasonableness, well changing 
it in a way that breaks things seems like the-anti-pattern of PBR.

I know from building with anvil and building RPMs that we only used tags 
in https://github.com/stackforge/anvil/tree/master/conf/origins because 
the PBR version number would change format/style/other (and also 
partially because nothing existed that converted to a *sane* rpm version 
string, although this supposedly exists now via a new PBR function).

Thierry Carrez wrote:
> Jeremy Stanley wrote:
>> On 2015-06-01 15:57:17 +0000 (+0000), Jeremy Stanley wrote:
>> [...]
>>> The biggest hurdle is that we'd need a separate upload job name
>>> for those since the current version of Zuul lacks a way to run a
>>> particular job for different branches in different pipelines (we'd
>>> want to do versioned uploads for all pre-release and release
>>> pipeline refs, but also for post pipeline refs only when the
>>> branch name is like stable/.*).
>> Actually, scratch that. It's a bit more complicated since the post
>> pipeline isn't actually branch-relevant. We'd need to tweak the
>> tarball and wheel creation scripts to check the containing branch,
>> like we do for some proposal jobs. Still, I think it wouldn't be too
>> hard.
>
> Exploring plan D, I was looking at the versions we currently generate on
> stable branches and I think they would not convey the right message:
>
> "2015.1.1.dev38"
>
> - but there won't be a 2015.1.1 !
> - but this is not "under development" !
>
> I was wondering if we could switch to post-versioning on stable
> branches, and basically generate:
>
> "2015.1.0.post38"
>
> ... which would convey the right message.
>
> I /think/ all it would take would be, as the first post-release commit
> to the stable branch, to remove the preversion from setup.cfg (rather
> than bump it to the next .1). I think pbr would switch to postversioning
> in that case and generate postX versions from the last tag in the branch.
>
> Not sure we would do that for stable/kilo, though, since we already
> pushed 2015.1.1.devX versions in the wild.
>