[gmx-developers] numbering of next GROMACS release

[Barnett, James W]

I think some form of full year (e) or year/month (f) version number would work well. My preference would be the full year, because it makes it even more clear when a person is using an out-of-date version.  Mentally there's a bigger difference between GROMACS 2008/2015 than GROMACS 4.0/5.1 ("I'm only using one major version older than the current version" vs. "I'm using software from 7 years ago").


--

James "Wes" Barnett, Ph.D. Candidate

Louisiana Board of Regents Fellow

Chemical and Biomolecular Engineering


Tulane University

341-B Lindy Boggs Center for Energy and Biotechnology

6823 St. Charles Ave
New Orleans, Louisiana 70118-5674

jbarnet4 at tulane.edu



________________________________
From: gromacs.org_gmx-developers-bounces at maillist.sys.kth.se <gromacs.org_gmx-developers-bounces at maillist.sys.kth.se> on behalf of Mark Abraham <mark.j.abraham at gmail.com>
Sent: Wednesday, August 19, 2015 6:56 AM
To: Discussion list for GROMACS development
Subject: [gmx-developers] numbering of next GROMACS release

Hi,

It's time to start discussions about future releases. Several of us think it would be a good idea to switch to a numbering scheme that reflects what we're actually doing - releasing the code at a particular point of time. Ubuntu does this with their 15.04 style numbering (YY.MM<http://YY.MM>) and so does Visual Studio with "2015" (though they also have a number behind the scenes). Other projects do as we have done and have a major and minor number that are bumped whenever people feel like it (e.g. our 4.0, stillborn 4.1, 4.5, 4.6, 5.0, 5.1). Major.minor is not a great fit for GROMACS because we're not in the business of promising certain features before we release. Some packages just have a number and bump it (AMBER), but that makes it tricky to handle patch releases (I think they just put up patch files and leave the user to work out how to use it).

In no case does what anybody numbers anything imply anything particular about the reliability of a release, so this is not a relevant consideration here. For example, Ubuntu LTS and RHEL promises to maintain for a long time and not to change stuff, but there's nothing particularly special about the reliability of such a version when it starts out - they still just picked a set of packages and tested it a bit.

So the options for a 2016 release are (in most cases, the next patch release will get a .1 suffix)
a) GROMACS 5.2 (no matter what)
b) GROMACS 5.2 (unless we feel like confusing ourselves by deciding on 6.0 later on)
c) GROMACS 6 (planning 7 next, plus some undecided scheme for numbering patch releases, but *not* 6.1)
d) GROMACS 6.0 (and probably planning 6.1 next)
e) GROMACS 2016
f) GROMACS 16.06 (and we won't change the month because we aren't going to let it slip; maybe this lets us consider doing 16.12 also)
g) other?

What do people think? Anyone voting for c) or g) needs to add detail.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20150819/6c1a8503/attachment.html>