Bug#798714: debian-policy: Please explicitly recommend punctuation between the year, month and day components of date based version numbers
On Fri, 11 Sep 2015, Axel Beckert wrote:
> To demonstrate my point, please sort the following version numbers in
> your head:
>
> * 20110111.0
> * 20101111.1
> * 20111111.2
These are rather bad, as you might need to use epochs. In fact, they go
against documented current best practice due to a lack of an initial field
that is not the date.
But they're utterly easy to sort on sight.
> * 9.20111211
> * 9.20111121
These, and similar variants (major.YYYYMMDD.minor) are good: Your eyes
easily lock on the several semanthic components of the version field, and
when you have any trouble, you just bump major without the need to resort to
epochs.
> And now compare the same dates, but written with punctuation:
>
> * 2011.01.11.0
> * 2010.11.11.1
> * 2011.11.11.2
> * 9.2011.12.11
> * 9.2011.11.21
Ugh. All of them look like something the cat dragged in as far as _I_ am
concerned. Others might disagree, of course: you clearly would. The point
is that this is controversial.
But what is really nasty IMHO is the fact that the same delimiter is used
for the date and for other semanthic components. I would not be nearly as
opposed to something like 9+2011.11.21+3, but I would still never use that
unless forced.
I'd rather leave '+' out of base version numbers, so as to have it stand out
for its other higher-level uses (we regularly use "+" for bin-NMUs, security
updates, stable updates, etc).
> So please change the above cited policy section in a way that it is
> clear that the "YYYY.MM.DD" format is preferred and the format without
Do you have statistics on the current patterns used in the archive? If most
are of the something.YYYY.MM.DD.something_else sort, I'd agree that it is
preferred.
> Here's a suggestion for an updated text:
>
> | […] the date-based portion of any upstream version number should be
> | given in a way that sorts correctly: four-digit year first, followed
> | by a two-digit numeric month, followed by a two-digit numeric date,
> | with punctuation between the components.
> |
> | […] Since punctuation is desired between the date components, remember
> | that hyphen (-) cannot be used in native package versions. Period (.)
> | is the recommended choice.
>
> P.S.: Yes, I'm aware that this doesn't help much for existing badly
> formatted date-based version numbers, as it would need an epoch to
> change it. But since many packages (like e.g. debhelper) use a prefix
> number anyway (e.g. 9.20150811), this could be changed when the date
> prefix is bumped the next time, e.g. to 10.2015.09.23 or so. And if
> someone thinks that makes it less obvious where the date starts, a
> different delimiter before the date could be chosen, e.g. 10+2015.09.23.
I oppose this change on several grounds.
1. I personally feel it is horrible beyond belief, i.e. this is highly
subjective matter with little technical reasons to mandate in one
way or the other.
2. -policy documents best current *ADOPTED* practice.
First, you get a sizeable fraction of the packages to implement it
(like >70%), which *might* warrant a _should_ in policy.
Then you get nearly everything to implement it, OR agreement in
-devel, or get it to become a release goal. That likely warrants
a _must_ in policy.
Even on non-normative sections, the spirit of (2) above should prevail.
Now, if you do the statistic work to show that the absolute majority of our
packages use "." as a delimiter inside dates, then it would make sense to
continue this thread on the grounds that is indeed already adopted common
practice -- but even in this case, a softer wording is likely required.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: