On Thu, 11 Jan 2018 22:21:50 -0800 Gregory Szorc <gregory.sz...@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. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel