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
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
