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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
