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
