<div dir="ltr">Hi,<div><br></div><div>Thanks for the feedback (here and elsewhere). People seem generally in favour of something that increases monotonically, indicates the age of the program, and that encourages fixed release cycles. There also needs to be a way to separate clearly a bug-fix release from a new-feature release. There's little enthusiasm now for more than one feature release per year.</div><div><br></div><div>So, unless/until we find a problem, we'll</div><div>* call the next release "GROMACS 2016"</div><div>* number its bug-fix releases 2016.1, 2016.2, etc. approximately every two months</div><div>* call its git branch "release-2016"</div><div>* support it for approximately a year (i.e. fix pretty much any issue arising on targeted platforms & simulations, "best effort" otherwise)</div><div>* <span style="line-height:1.5;font-size:13.1999998092651px">retain the option to make another bug fix release at some future time (generally only if some serious MD-correctness issue has been fixed)</span></div><div><br></div><div>Mark</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 20, 2015 at 6:28 PM Justin Lemkul <<a href="mailto:jalemkul@vt.edu">jalemkul@vt.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 8/19/15 4:24 PM, Erik Lindahl wrote:<br>
> I agree with James; I've seen several cases where people had no idea they were<br>
> using versions that were several years old...<br>
><br>
> It would also be nice to get rid of the permanent question whether changes are<br>
> large enough to warrant a full version bump.<br>
><br>
<br>
I would be in favor of a versioning scheme that also has fixed intervals. For<br>
instance, if we have a new version called GROMACS-2016.1 that is released in<br>
January 2016 (hence 1 for the month) and then we release periodically through<br>
the year (April = 2016.4, July = 2016.7, etc). This is what CHARMM does - we<br>
have regular releases in February (alpha version) and August (final version).<br>
The 2016.x numbering can be whatever month the version is released, and whatever<br>
doesn't make the cut, doesn't make the cut. Have a feature freeze a couple of<br>
weeks before the first of the new month when we want a release to deal with code<br>
review and we're set. In this way, we eliminate a lot of delays we've had in the<br>
past for holding off on releases, unless there's something really major that<br>
needs to get fixed.<br>
<br>
-Justin<br>
<br>
><br>
> Cheers,<br>
><br>
> Erik<br>
><br>
> Erik Lindahl <<a href="mailto:erik.lindahl@scilifelab.se" target="_blank">erik.lindahl@scilifelab.se</a> <mailto:<a href="mailto:erik.lindahl@scilifelab.se" target="_blank">erik.lindahl@scilifelab.se</a>>><br>
> Professor of Biophysics<br>
> Science for Life Laboratory<br>
> Stockholm University & KTH<br>
> Office (SciLifeLab): +46 8 524 81567<br>
> Cell (Sweden): +46 73 4618050<br>
> Cell (US): +1 267 3078746<br>
><br>
><br>
> On 19 aug 2015, at 16:27, Barnett, James W <<a href="mailto:jbarnet4@tulane.edu" target="_blank">jbarnet4@tulane.edu</a><br>
> <mailto:<a href="mailto:jbarnet4@tulane.edu" target="_blank">jbarnet4@tulane.edu</a>>> wrote:<br>
><br>
>> I think some form of full year (e) or year/month (f) version number would work<br>
>> well. My preference would be the full year, because it makes it even more<br>
>> clear when a person is using an out-of-date version. Mentally there's a<br>
>> bigger difference between GROMACS 2008/2015 than GROMACS 4.0/5.1 ("I'm only<br>
>> using one major version older than the current version" vs. "I'm using<br>
>> software from 7 years ago").<br>
>><br>
>><br>
>> --<br>
>><br>
>> James “Wes” Barnett/, /Ph.D. Candidate<br>
>><br>
>> Louisiana Board of Regents Fellow<br>
>> //<br>
>><br>
>> Chemical and Biomolecular Engineering<br>
>><br>
>><br>
>> Tulane University<br>
>><br>
>> 341-B Lindy Boggs Center for Energy and Biotechnology<br>
>><br>
>> 6823 St. Charles Ave<br>
>> New Orleans, Louisiana 70118-5674<br>
>><br>
>> <a href="mailto:jbarnet4@tulane.edu" target="_blank">jbarnet4@tulane.edu</a> <mailto:<a href="mailto:jbarnet4@tulane.edu" target="_blank">jbarnet4@tulane.edu</a>><br>
>><br>
>><br>
>><br>
>><br>
>> --------------------------------------------------------------------------------<br>
>> *From:* <a href="mailto:gromacs.org_gmx-developers-bounces@maillist.sys.kth.se" target="_blank">gromacs.org_gmx-developers-bounces@maillist.sys.kth.se</a><br>
>> <mailto:<a href="mailto:gromacs.org_gmx-developers-bounces@maillist.sys.kth.se" target="_blank">gromacs.org_gmx-developers-bounces@maillist.sys.kth.se</a>><br>
>> <<a href="mailto:gromacs.org_gmx-developers-bounces@maillist.sys.kth.se" target="_blank">gromacs.org_gmx-developers-bounces@maillist.sys.kth.se</a><br>
>> <mailto:<a href="mailto:gromacs.org_gmx-developers-bounces@maillist.sys.kth.se" target="_blank">gromacs.org_gmx-developers-bounces@maillist.sys.kth.se</a>>> on behalf of<br>
>> Mark Abraham <<a href="mailto:mark.j.abraham@gmail.com" target="_blank">mark.j.abraham@gmail.com</a> <mailto:<a href="mailto:mark.j.abraham@gmail.com" target="_blank">mark.j.abraham@gmail.com</a>>><br>
>> *Sent:* Wednesday, August 19, 2015 6:56 AM<br>
>> *To:* Discussion list for GROMACS development<br>
>> *Subject:* [gmx-developers] numbering of next GROMACS release<br>
>> Hi,<br>
>><br>
>> It's time to start discussions about future releases. Several of us think it<br>
>> would be a good idea to switch to a numbering scheme that reflects what we're<br>
>> actually doing - releasing the code at a particular point of time. Ubuntu does<br>
>> this with their 15.04 style numbering (<a href="http://YY.MM" rel="noreferrer" target="_blank">YY.MM</a> <<a href="http://YY.MM" rel="noreferrer" target="_blank">http://YY.MM</a>>) and so does<br>
>> Visual Studio with "2015" (though they also have a number behind the scenes).<br>
>> Other projects do as we have done and have a major and minor number that are<br>
>> bumped whenever people feel like it (e.g. our 4.0, stillborn 4.1, 4.5, 4.6,<br>
>> 5.0, 5.1). Major.minor is not a great fit for GROMACS because we're not in the<br>
>> business of promising certain features before we release. Some packages just<br>
>> have a number and bump it (AMBER), but that makes it tricky to handle patch<br>
>> releases (I think they just put up patch files and leave the user to work out<br>
>> how to use it).<br>
>><br>
>> In no case does what anybody numbers anything imply anything particular about<br>
>> the reliability of a release, so this is not a relevant consideration here.<br>
>> For example, Ubuntu LTS and RHEL promises to maintain for a long time and not<br>
>> to change stuff, but there's nothing particularly special about the<br>
>> reliability of such a version when it starts out - they still just picked a<br>
>> set of packages and tested it a bit.<br>
>><br>
>> So the options for a 2016 release are (in most cases, the next patch release<br>
>> will get a .1 suffix)<br>
>> a) GROMACS 5.2 (no matter what)<br>
>> b) GROMACS 5.2 (unless we feel like confusing ourselves by deciding on 6.0<br>
>> later on)<br>
>> c) GROMACS 6 (planning 7 next, plus some undecided scheme for numbering patch<br>
>> releases, but *not* 6.1)<br>
>> d) GROMACS 6.0 (and probably planning 6.1 next)<br>
>> e) GROMACS 2016<br>
>> f) GROMACS 16.06 (and we won't change the month because we aren't going to let<br>
>> it slip; maybe this lets us consider doing 16.12 also)<br>
>> g) other?<br>
>><br>
>> What do people think? Anyone voting for c) or g) needs to add detail.<br>
>><br>
>> Mark<br>
>> --<br>
>> Gromacs Developers mailing list<br>
>><br>
>> * Please search the archive at<br>
>> <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
>><br>
>> * Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
>><br>
>> * For (un)subscribe requests visit<br>
>> <a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or<br>
>> send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a><br>
>> <mailto:<a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>>.<br>
><br>
><br>
<br>
--<br>
==================================================<br>
<br>
Justin A. Lemkul, Ph.D.<br>
Ruth L. Kirschstein NRSA Postdoctoral Fellow<br>
<br>
Department of Pharmaceutical Sciences<br>
School of Pharmacy<br>
Health Sciences Facility II, Room 629<br>
University of Maryland, Baltimore<br>
20 Penn St.<br>
Baltimore, MD 21201<br>
<br>
<a href="mailto:jalemkul@outerbanks.umaryland.edu" target="_blank">jalemkul@outerbanks.umaryland.edu</a> | (410) 706-7441<br>
<a href="http://mackerell.umaryland.edu/~jalemkul" rel="noreferrer" target="_blank">http://mackerell.umaryland.edu/~jalemkul</a><br>
<br>
==================================================<br>
--<br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
</blockquote></div>