[Openstack-operators] Operations project: Packaging
mgagne at iweb.com
Wed Nov 19 23:07:58 UTC 2014
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:
> 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. =)
More information about the OpenStack-operators