Switching to a date-based version scheme?

[Gregory Szorc]

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?"

I'd like to propose changing Mercurial's versioning scheme so it is based
on release date. This versioning scheme would reinforce the reality of
Mercurial's time-based release cadence and help average users understand
how old their Mercurial release is. It would not sacrifice adherence to
semantic versioning compared to what we do currently.

There is certainly room to bikeshed time based versioning schemes. I'll
suggest a scheme that is similar to how we currently do things:
YY.[M]M.[N]N, where:

YY = 2000 - current calendar year (2018 = 18)
[M]M = month of major release (January = 1, December = 12)
[N]N = Point release (initial = 0, subsequent N+1)

So, the next release of Mercurial would be 18.2.0, corresponding to
February 2018. Point releases would be 18.2.1, 18.2.2, 18.2.3, etc. The
next quarterly release would be 18.5.0 (May 2018). Then 18.8.0 and 18.11.0.
A year from now, we'd release 19.2.0.

Random questions...

If we only release quarterly, why not use 1, 2, 3, 4 for the minor version
component? Using the month reinforces the date based nature of the release
mechanism. If we ever decide to move to a faster or slower major release
cadence, a minor version component reflecting the month doesn't need to
change semantic meaning.

Why use 1, 2, 3 as opposed to 01, 02, 03, etc? This should be an arbitrary
decision. Padding zeros would provide some defense against tools that do a
bytes-level string comparison. However, tools shouldn't be using string
compare for version sorting. PEP 440 says that leading 0s should be ignored
in integer version fields. Even the Linux kernel doesn't use zero padding.
We /could/ use 0 padding if people feel it is needed. But it shouldn't be
necessary.

Since major versions are quarterly, why not combine the year and month
components into the same version field? e.g. 201802.0 instead of 2018.2.0.
This is a reasonable bikeshed to have. If we want to have stronger semantic
versioning guarantees, combining the year and month components into a
single field to reflect the actual API guarantees does make sense. But API
guarantees are what we define them to be. Only purists care about whether
API compatibility is preserved between <major>.<minor> or just <major>.
Until we start providing libraries with strong backwards compatibility
guarantees, it doesn't really matter.

Thoughts?

If adopted, what would need changed?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20180111/8564a394/attachment.html>