Hi guys,
I'd like to gather some input on versioning schemes used for packaging
SCM snapshots. Why do we care at all? Ignoring the source pkg and the
changes file for the moment, the package version is meant to tell the
user exactly which state of the software was provided to him. When you
package an upstream tarball, you implicitly provide information about
what was released and when. And the package build is reproducable, it
won't change how often you download the tarball referenced in Source:.
Thus it's enough to just have sth. like this in your spec file:
Version: 1.2.3
So if you have to package a (random) SCM snapshot, you want to make sure
that it's obvious which commit you picked, so that others can confirm
and eventually repeat the build. Here's a small list of flavors that
I've come across or used myself. Please not that I replaced the stable
(upstream) version with X, since that's not the part I'm interested
here. Also, the word "git" can be replaced by whatever SCM at hand:
1) X+git
2) X_20041122git
3) X+git20111213
4) X.a258.g003e7e3
5) X+git.1363873583.8dfab15
Albeit you can discuss the format differences, 2) and 3) are much better
than 1) since they at least broadly state when the SCM snapshot was
taken. 4) Does a better job by providing the commit number/hash but
breaks RPM upgradeability. Random commit hashes aren't upgradeable
right? So the best version is indeed number 5), where the first number
is the commit date and the second one is the commit hash. The date
assures upgradability, because it increments always linearly and the
commit hash provides for reproducability.
You can of course argue about dots vs, any other separating paragraph.
Also, instead of "+git", you may prefer sth. different (along as it
won't break RPM's version comparison mechanism).
TL;DR
=====
My recommendation would be to (at least loosely) follow pattern 5)
versioning if you ever have to package from SCMs. While devel projects
are rather free to do whatever they prefer, I'd say it's appropriate for
Factory submissions.
Bonus
=====
There is absolutely no reason to do this manually. Use the tar_scm
source service (in disabled or local_only mode !!!) if you want to fully
automate this. Here are some examples:
Cloud:OpenStack:Master / openstack-utils
devel:languages:go / go-assert
--
Sascha Peilicke
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)