Open Stack

To get around the PBR versioning issue right now we use annotated tags for
each "release" that we build and then we update the release number inside
anvil for that component to be one higher than the current package. So
that we get sanely tagged/versioned packages.

For example, our version of nova compute is:
openstack-nova-compute-2014.1.2.5.gdicehouse.2-5.  Where gdicehouse-5 is
the current build off of our 2014.1.2.5 branch.  Which is has patches that
we are carrying that are based on top of 2014.1.2.  The next build will
most likely be: openstack-nova-compute-2014.1.2.5-gdicehouse.2-6.

We actually have some automation around the incrementing the version
number that was tied into our specific infrastructure so it wasn't manual.
 Also, I don¹t know why PBR only supports annotated tags vs's lightweight
tags - the fix for that iirc is/was pretty trivial.

____________________________________________
 
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy, LLC.


On 11/19/14, 4:07 PM, "Mathieu Gagné" <mgagne at iweb.com> wrote:

>On 2014-11-19 5:01 PM, Joshua Harlow wrote:
>> That sort of makes the operator/package builder then solely responsible
>> for knowing what the versions should be right? Once used it becomes no
>> longer pbr's job to figure out a right version, which works ok as long
>> as u have the appropriate infrastructure to do this correctly (and
>> meticulously follow this). That seems like extra work that I'd rather
>> not get involved in :-P
>
>I agree with you that it might not be what other operators are looking
>for. I (wrongfully?) assumed that Kris had a more clever way to generate
>his own version numbers and was instead only looking for a way to bypass
>PBR auto-version system.
>
>Should Kris not have such alternative versioning system, what should it
>be?
>
>If you create your own branch, how should versioning work?
>
>Should it be the number of commits since the last annotated tag? What if
>you are updating some details about your packaging system and rebuiling
>against the exact same commit, won't you have duplicated versions?
>
>Unless you are planning on tagging your own internal releases before
>building your packages, I see a lot of potential issues with
>auto-versioning provided by PBR as mentioned above.
>
>People who talked about their packaging systems at the OpenStack Summit
>often recommended using the date/time to construct the version number.
>Therefore unless you are packaging the exact same project in parallel or
>going back in time, there is little risk of duplicated version numbers.
>
>
>> For something like a git-hash I recall there was going to be some
>> inbuilt pbr support for extracting a valid rpm-version that would be
>> valid even for git-hashes without having to start overriding the version
>> via PBR_VERSION. This would be the ideal case, to always have a version
>> that works come from PBR's version automagic code, either if its a
>> git-hash, a tag, or something else...
>
>PBR provides facilities to generate rpm/debian compatible version
>numbers as per the doc:
>https://github.com/openstack-dev/pbr/blob/master/doc/source/index.rst
>
> > The version.SemanticVersion class can be used to query versions of a
> > package and present it in various forms - debian_version(),
> > release_string(), rpm_string(), version_string(), or version_tuple().
>
>I'm not sure how someone could use it to override the default PBR
>versioning logic though.
>
>
>> I think that code might be in an unreleased PBR code base but I'm not
>> 100% sure (it was connected to the sem-ver code that got added since
>> sem-ver calculates the version and then there was a translation to a rpm
>> version), I don't see `python setup.py --help` having a new command that
>> could get this version so I'm guessing thats still the case.
>
>See above. =)
>
>-- 
>Mathieu