Open Stack

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