<div dir="ltr">Hi,<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 6, 2015 at 2:35 PM Szilárd Páll &lt;<a href="mailto:pall.szilard@gmail.com">pall.szilard@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><div>On Mon, Oct 5, 2015 at 10:43 PM, Mark Abraham <span dir="ltr">&lt;<a href="mailto:mark.j.abraham@gmail.com" target="_blank">mark.j.abraham@gmail.com</a>&gt;</span> wrote:<br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>It&#39;s time for some more releases. I&#39;ll do 5.0.7 later this week, and 5.1.1 shortly after.</div><div><br></div><div>release-4-6 is now closed (Michael has an outstanding patch, but we can apply its fix elsewhere if suitable). I think we should default to blocking uploads to closed branches, unless there&#39;s a reason to permit it. I&#39;ll look into doing that. Then I&#39;ll archive the Jenkins configurations somewhere, and remove the jobs.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>There have been numerous important fixes in the 4.6 branch, at least 3-4 critical ones, so a final goodbye 4.6 would be useful (plus I though this this has been discussed if not agreed upon before), btu I may be mistaken.</div></div></div></div></blockquote><div><br></div><div>I don&#39;t see anything that&#39;s likely to lead to wrong results to a significant portion of users. I&#39;m open to specific counter-arguments, but &quot;the code&#39;s been fixed&quot; is not sufficient.</div><div><br></div><div>A new release to share a fix for an issue that&#39;s rare, or only affects a niche use case isn&#39;t worth the day of my time to do the release, and the time of everybody else to consider whether they should use the new version, and then getting it installed (in lots of places). Suiting the convenience of a small number of people affected has to be compared with their alternative strategy of installing a more recent version that already has the relevant fix. In many cases, &quot;4.6.7 has a bug, so I switched to using 5.1 where it&#39;s already fixed&quot; is clearly a good solution, and often the best one.</div><div><br></div><div>Alternatively, if someone else wants to take over the release management role, they can spend their time on whatever niche things they value. :-)</div><div><br></div><div>Mark</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>release-5-0 is now only open for serious scientific correctness fixes, e.g. mdrun or some analysis tool is wrong. There will be a future release only if we judge it is clearly useful</div><div><br></div><div>release-5-1 is open for general fixes of things that don&#39;t quite do what we meant them to do. Such changes must not change correct functionality, and change as few things as necessary to do the job reasonably. Invasive or risky fixes should go on master branch. There will be future releases roughly every 2 months.</div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> </div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>master is open for general business, including cleanup, features, fixes.</div><span><font color="#888888"><div><br></div><div>Mark</div></font></span></div>
<br></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">--<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&#39;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>
--<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&#39;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>.</blockquote></div></div>