[gmx-developers] upcoming point releases; also updates to branch statuses
Mark Abraham
mark.j.abraham at gmail.com
Tue Oct 6 17:08:31 CEST 2015
Hi,
On Tue, Oct 6, 2015 at 2:35 PM Szilárd Páll <pall.szilard at gmail.com> wrote:
> On Mon, Oct 5, 2015 at 10:43 PM, Mark Abraham <mark.j.abraham at gmail.com>
> wrote:
>
>> Hi,
>>
>> It's time for some more releases. I'll do 5.0.7 later this week, and
>> 5.1.1 shortly after.
>>
>> 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's a reason to permit it. I'll look
>> into doing that. Then I'll archive the Jenkins configurations somewhere,
>> and remove the jobs.
>>
>
> 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.
>
I don't see anything that's likely to lead to wrong results to a
significant portion of users. I'm open to specific counter-arguments, but
"the code's been fixed" is not sufficient.
A new release to share a fix for an issue that's rare, or only affects a
niche use case isn'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, "4.6.7 has a bug, so I switched to using
5.1 where it's already fixed" is clearly a good solution, and often the
best one.
Alternatively, if someone else wants to take over the release management
role, they can spend their time on whatever niche things they value. :-)
Mark
> 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
>>
>> release-5-1 is open for general fixes of things that don'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.
>>
>
>>
>
>> master is open for general business, including cleanup, features, fixes.
>>
>> Mark
>>
>> --
>> Gromacs Developers mailing list
>>
>> * Please search the archive at
>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
>> posting!
>>
>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>
>> * For (un)subscribe requests visit
>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
>> or send a mail to gmx-developers-request at gromacs.org.
>>
>
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20151006/ee29804b/attachment.html>
More information about the gromacs.org_gmx-developers
mailing list