On 12/01/16 19:26, Ludovic Courtès wrote:
Ricardo Wurmus <rek...@elephly.net> skribis:
Should we also take some time to reconsider how we name unreleased
versions like arbitrary git commits?
Let do that!
Lets.
So far we have been picking the latest release version (or “0.0.0” if
there hasn’t been any release) followed by “.” and either a date or a
guix-internal revision number, then again a “.” followed by part of the
commit hash.
I’m afraid that we might accidentally introduce conflicts with future
release versions, e.g. when the latest release only uses two digits
(e.g. “0.1”) and we add a revision or a date (e.g. “0.1.1” or
“0.1.20160112”) and the next release and the next official release
switches to three digits (e.g. “0.1.1”).
Would it make sense to separate our version identifier from the actual
release version with a different character than “.”? Or should this be
discussed elsewhere as it hasn’t anything to do with how we specify
versions on the command line?
Probably. Debian, for instance, uses “2.0.11-9” where “9” denotes the
9th package revision of upstream version “2.0.11”. We could probably
use that convention.
In a previous discussion on this topic, I suggested that we should have
such a revision number instead of just “x.y.COMMIT”. The extra
monotonically-increasing revision number is needed to allow upgrades to
work as expected.
So, a Git snapshot’s version number could be:
2.0.11-3.deadbeef
^ ^ ^
| | `— upstream commit ID
| |
| `—— 3rd Guix package revision
|
latest upstream version
The next snapshot would be:
2.0.11-4.cafeefac
WDYT?
I can't see anything wrong with this myself. Is this accepted policy now?
Also, is the convention for unreleased software to take 0.0.0 as the
version as you suggest Ricardo e.g. 0.0.0-1.deadbeef ?
ta
ben
