<div dir="ltr"><div>Sorry for the late reply, I've admittedly forgot to finish up the mail and send it off in time -- sorry about that. Still I do think it's relevant as feedback, so I'll include it below.</div><div><br></div><div>Regarding the proposal presented by Mark, with the patch versioning retained I wonder what is the major practical benefit to switching to a different versioning scheme (beside communicating the date for which I do think there are equally good ways - see below).</div><div><br></div><div>Cheers,</div><div>Sz.</div><div><br></div><div>=======</div><div><br></div><div><br></div><div><br></div>I prefer b): new minor release unless the dev community feels like major changes warrant otherwise (decision after feature freeze).<div><br></div><div>Alternatively, if we feel that there is no need to distinguish between major/minor changes, c) would be fine too. Admittedly, I'm not entirely sure, but I do think there is value in the subtle message of major version bump, e.g. I do think 5.0 marking the beginning of the C++ transition is a nice indicator that's easy to remember.</div><div><div><br></div><div><br><div><br></div><div>I vote against f) and I'm not too fond of e) either.</div><div>My problem with date-based versioning (especially the YEAR.MONTH scheme) and short release cycles is that chasing dates with a rather small team of almost exclusively (busy scientist) volunteers sounds dangerous. <br></div><div>Given the limited amount of man-power fully/mostly devoted to code development and testing, putting too much emphasis on the date can mean a lot of stress and frustration in the last few weeks. Even with e.g. ~6-7 weeks room from feature freeze to release, nobody can expect the owner/maintainer/closest "friend" of some code to fix a blocker issue, no matter how tight or strict the deadline is - especially if the issue is found halfway through the 6 weeks. This person may be busy or on vacation or whatever. And Mark or anyone else should not have to pick up the burden of diving in the code just to make a deadline.</div><div><br></div><div>Regarding James'+Erik's point on dates, I see a simple solution for that: have every gmx command print the release date (possibly as a large ASCII-art). That way every user will know how old is their release. This seems to be a useful replacement for the author/contributor list which IMO does not need to be printed every time a gmx tool runs. Plus, if a release cycle of ~12 months can be assumed, after say 24 months from the x.y.0 release, an explicit warning could be issued.</div><div><div><div><div><div><br></div></div></div></div></div></div></div><div class="gmail_extra"><br clear="all"><div><div>--<br>Szilárd</div></div>
<br><div class="gmail_quote">On Wed, Aug 19, 2015 at 1:56 PM, Mark Abraham <span dir="ltr"><<a href="mailto:mark.j.abraham@gmail.com" target="_blank">mark.j.abraham@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>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 (<a href="http://YY.MM" target="_blank">YY.MM</a>) 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).</div><div><br></div><div>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.</div><div><br></div><div>So the options for a 2016 release are (in most cases, the next patch release will get a .1 suffix)</div><div>a) GROMACS 5.2 (no matter what)</div><div>b) GROMACS 5.2 (unless we feel like confusing ourselves by deciding on 6.0 later on)</div><div>c) GROMACS 6 (planning 7 next, plus some undecided scheme for numbering patch releases, but *not* 6.1)</div><div>d) GROMACS 6.0 (and probably planning 6.1 next)</div><div>e) GROMACS 2016</div><div>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)</div><div>g) other?</div><div><br></div><div>What do people think? Anyone voting for c) or g) needs to add detail.</div><span><font color="#888888"><div><br></div><div>Mark</div></font></span></div>
<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><br></div></div>