On Tue, 10 Sep 2013, Sascha Peilicke wrote:
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?
One extra issue is to ensure upgradeability of whatever existing
scheme is in use to the new scheme. rpm epoch anyone? ;)
I've been relucant to change gcc from using gcc48-4.8.1_20130909
to gcc48-4.8.1_202388 for that reason. Unfortunately
gcc48-4.8.1_20130909 is not upgradeable to gcc48-4.8.1_svn202388
so I have to wait for GCCs svn revision to increase beyond
20130909 ;) Or use a different separator (+ and . match _ but
- would be newer).
Richard.
--
Richard Biener