Python 3 Transition Plan / Calendar Versioning

[Anton Shestakov]

On Tue, 8 Oct 2019 18:26:46 -0700
Gregory Szorc <gregory.szorc at gmail.com> wrote:

> I referred to the releases by calendar date because at the 5.2 Sprint we
> decided to adopt calendar versioning starting with the first Mercurial
> release that is Python 3 only.
> 
> Our new versioning scheme will be YYYY.[M]M.N. e.g. 2020.5.0 or 2020.10.1.
> This scheme consists of the 4 digit year, a 1-2 digit month, and a
> monotonically increasing point release, starting at 0. This scheme is
> compatible with our existing versioning scheme, has a major version that is
> greater than 5, and doesn't have a leading 0 in the month field (which
> could confuse version parsers).

I'm glad to see that this idea has been improved since the last
proposal, and 4 digit year is indeed better than 2 digit year ("2020"
is way less ambiguous than just "20"). The paragraph above doesn't show
how would point releases handle the dates, but let's say it's 2020.2.0
for feature, 2020.3.1 and 2020.4.2 for bug fixes. The format has some
elements of semantic versioning (the last digit), which is nice for
maintainers to see what kind of release that would be at a glance.
Although it is confusing to users because of two different ideas used
in one version string. But I guess it's less scary?

> Succinctly, we decided to adopt calendar versioning because Mercurial's
> version numbers don't have much semantic meaning and may confuse users who
> think the major version number changes imply breaking changes. Furthermore,
> calendar versions may help users better understand how old their Mercurial
> version is.

Technically the date-version format also means that when there are
breaking changes, there wouldn't be any way to imply that anymore.

Then there's of course the problem that I've already described the last
time date-based versions were proposed: knowing how old their Mercurial
version is not helpful on its own.

What should people do if their software is old? Probably update it. But
their current version string doesn't say if there's an update
available. I'd like to put emphasis on this: some software being 1 year
old doesn't tell anything about its current state. Was it abandoned or
were there already hundreds of bug-fix releases for it? Infer that from
"2020.2.0". In case of Mercurial, this means that unless users already
know of our time-based release plan, they need to check m-s.o and see
if there was a new release.

That is, if users even know the version of Mercurial they use. They
don't just magically know software version just by having it available,
nor by using said software. They need to look it up, and one way to do
this is by running `hg version`. So why can't `hg version` also just
show the date when that version was released? Going even a bit further,
if we have time-based release plan, we can just tell people that a new
version may be available to download when they run `hg version`. No
calling home needed, because every month there's something new. It even
can say if it's a feature or a bug-fix release.

Oh wait, users can also just check their version in their package
manager and never see `hg version` output. Except if they use package
managers for Mercurial, then they should've either already received all
updates, or they are stuck with whatever version they are provided by
the distro. What's the course of action for Ubuntu users if their
package manager says their Mercurial is old? We used to have a PPA that
had updated packages, but it's abandoned now. We also have Centos and
Fedora repos on m-s.o, but there are no new packages there either. And
we sure don't make available packages even for Debian, let alone less
popular distros. Our website may suggest a tarball that people need to
compile themselves or an older version for whatever reason. People
forget to update Mercurial/NewsItems page with a new release for weeks,
UpgradeNotes (that thing that mentions breaking changes) is sometimes a
couple of releases old. And I don't think these are problems that could
be easily solved, especially not with just a version format change.

So no, I don't support dates as versions, in part because it is not
useful to just know how old a certain version of Mercurial is (and it's
not like people can't look that version up at WhatsNew or NewsItems or
wikidata), but mostly because even when users do want to upgrade, they
can't do it easily. The dates as versions in this context looks worse
than the current versions scheme, because before wanting to not scare
users by a version string, we need to make sure they feel safe
upgrading to the new release (e.g. by words, in release notes) and
_can_ actually do it without jumping through hoops. How good is hinting
that they are using old software to users if they can't easily upgrade
it? That's just frustrating.