Switching to a date-based version scheme?

[Anton Shestakov]

On Thu, 11 Jan 2018 22:21:50 -0800
Gregory Szorc <gregory.szorc at gmail.com> wrote:

> Mercurial's version numbers (currently 4.4, soon to be 4.5) mean little to
> nothing. Mercurial's existing <major>.<minor>.<point> version scheme
> doesn't honor semantic versioning in the traditional sense. API guarantees
> are that each quarterly X.Y release generally maintains API compatibility
> within the release but there are no guarantees between quarterly releases.
> The <major> component of the version scheme is incremented when <minor>
> would hit 10 - not when there is a major API change. (This is an arbitrary
> decision since it is technically possible to have version components with
> an absolute value >=10.)
> 
> To the typical user who isn't intimately familiar with Mercurial's
> versioning and release strategy, the existing versioning scheme means
> little to nothing.
> 
> A typical user does care about something: whether their Mercurial is up to
> date.
> 
> One way of determining if something is up to date is asking "how old is it?"

FWIW, here are my thoughts about putting date of release into version.

First, let's consider something that's still active, but not doing
time-based release plan. If a typical user looks at something like TeX
3.1415926, which was last released in January 2014 (let's say they
somehow knew that), how would that help them, what would they think?
"There has to be an update by now, it's been 4 years already", right?
No, it's actually the latest TeX release. So the assumption that some
period of time (now - releasedate) means there's an update available
only works if that user is, well, at least somewhat familiar with
Mercurial's release strategy.

18.2.0 may look like it was released in February 2018, but what does
18.2.1 look like? Was it released February 1st? What about 18.2.2, how
old is it? Would users need to know and remember our versioning scheme
to tell that offhand?

And if we do YY.M (18.2, 18.3, 18.4) instead, that will completely
obfuscate if a version is a feature release or a bug-fix release. I
think at least package maintainers care about that.

Also, users may not realize that 18.2.0 means it was released in
February 2018 at all, unless they also, for example, look at previous
versions... or look it up on our site. In fact, why not just look at
our site to see how old their version is, and, of course, if there's an
update available. Even Wikipedia has this information.