Bug#798714: debian-policy: Please explicitly recommend punctuation between the year, month and day components of date based version numbers
Hi Russ,
thanks for your insight on that topic.
Russ Allbery wrote:
> Axel Beckert <abe@debian.org> writes:
>
> > To demonstrate my point, please sort the following version numbers in
> > your head:
>
> > * 20110111.0
> > * 20101111.1
> > * 20111111.2
> > * 9.20111211
> > * 9.20111121
>
> > 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
>
> For me, the first block is much clearer than the second block, since it
> makes it more obvious that those are dates.
That's surprising to me. I have clearly more issues to recognize an
8-digit number as a date at all than a 4-digit and a pair of 2-digit
numbers with delimiters.
> With the second, I have a lot more confusion over whether those are
> actually minor and patch release versions.
Well, how can you read minor and patch release versions out of a date?
That's the one thing which annoys me with _every_ date based version
number. (I'm actually a fan of the idea of Semantic Versioning,
http://semver.org/. But we're getting off-topic here. :-)
> I don't have a lot of trouble sorting them in my head.
Especially with debhelper releases I had problems remembering a
version number I saw and telling if another one is higher or lower. I
found that very annoying.
> I realize that people vary, and the fact that I don't have trouble doesn't
> mean other people won't.
Same here. Only that I haven't seen any such clear statement of the
opposite side like your's before. (Most discussions I had about
version numbers so far were mostly about date-based vs
semantic-versioning.)
> (Obviously, dashes would be even better than either periods or nothing,
> but sadly that adds a bunch of additional complexity.)
Well, I guess dashes versus periods is more a cultural thing. I
consider periods the best and "natural" way, but I think dashes would
be nice for non-date delimiters if they wouldn't be in use for
delimiting the Debian revision.
> Now, the one thing I'd add there is that I *do* use periods as you
> describe for packages where the version is *only* a date.
There we obviously agree. :-)
> The confusion that I see only happens when you're adding a version
> and a date, since then my brain sees four parts and really struggles
> with parsing it as a date.
I agree that a pure date (with periods as delimiters) is easier to
recognize than any such date with an additional period-delimited
prefix or suffix.
I though still prefer it over the variant with no delimiters inside
the date.
I also remember scientific studies saying that humans as well as some
animals can count to four without actually counting, but have issues
immediately telling the number of items if they're five or more items.
So it is for me with digits in 8-digit dates. I first have to count
the digits and then have to split them up into 4-2-2 chunks to be able
to parse it as date, which feels tedious.
> Plus sort of helps a little, but 9+2011.12.11 still looks rather confusing
> to me. I expect that version to indicate a Git snapshot of development
> following a version 9 release.
Granted. But there are no other characters left. Colon and dash can
only be used if there is already an epoch respectively a debian
revision. And a tilde has its own special meaning.
Regards, Axel
--
,''`. | Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Reply to: