[gmx-developers] Gromacs 4.0.5 released?

[hessb at mpip-mainz.mpg.de]

Hi,

One can actually, in http://www.gromacs.org/content/view/181/132/
Release notes for 4.0.4
...
Fixed bug in 4.0.3: the pull code would segv or produce strange distances
non-parallel with more than one atom per pull group (parallel runs were
correct).

This bug caused very serious artifacts that the user would clearly
notice, it could not lead to wrong results being seen as correct.

Although there have been many (small) bugs and bugfixes lately,
there have been extremely little that produced such small errors
that a user would not notice the issue.

Berk

> If one switches gromacs version in any way during a project, then I
> believe that the paper should reflect that in the methods. I would
> rather not write something like that in my own methods section, which
> is why I am strongly adverse to switching versions in any way during a
> single run. Here's an example of what can go wrong:
>
> http://www.gromacs.org/pipermail/gmx-users/2009-January/039181.html
>
> And I don't believe that one can find that in release notes.
>
> Chris.
>
>
>> Just to offer up my two cents on part of this:
>>>>
>>>> Sorry, we'll announce it :-) Actually, this was mostly a fix for a
>>>> powerpc build in Barcelona and rather than doing a separate build I
>>>> figured I could pack what we had in the release branch for everybody.
>>>> In the future, I would probably prefer to move to a setup where we
>>>> semi-automatically release a new version from the release branch
>>>> every 2-3 weeks (together with nightly builds). Every time we
>>>> formally "prepare" for a release there ends up being "just one more
>>>> fix" that should go in - two days later the first person doesn't
>>>> have time to make the release, and then we wait another week, after
>>>> which there is "just one more fix", etc. ;-)
>>>
>>> Would such frequent releases cause problems with version
>>> consistency?  I always try to conduct my projects using the latest
>>> version of Gromacs (which is always recommended to make use of bug
>>> fixes and new features), but if we have new versions every few
>>> weeks, are users then encouraged to continue existing simulations
>>> under newer versions?  Certainly moving from 3.3.x to 4.0.x wouldn't
>>> make much sense, with all the lovely 4.0 features that are new; I'm
>>> referring mostly to minor revisions within the 4.0.x series.
>>>
>>
>> My take on this is that (a) frequent releases are good, because this
>> will allow people to use a version that incorporates known bugfixes.
>> In previous versions sometimes there have been many bugfixes floating
>> around that one would need to apply to have a bug-free code to run.
>> But (b) a particular project should always be done with ONE particular
>> version of GROMACS (either a particular point release, a particular
>> CVS branch & checkout date, etc.), with no switching in the middle,
>> except under exceptional circumstances. The idea should be that we
>> provide enough information in our papers that another group can
>> reproduce our calculations; this includes specifying what version of
>> the code was used for all calculations, which is a lot more difficult
>> if one switches codes during a project.
>
> Minor revisions (such as 4.0.4 -> 4.0.5) should ONLY contain real
> bug fixes, no new features.
> Therefore you can always update, even within one project,
> since if your results change, this most probably means there have been
> affected by a bug.
> I always try to keep output binary identical between major revisions.
>
> On the other hand, you can check the release notes, which are now
> always up to date, and see if any bug fix affects your system
> and only update within a project when there is such a fix.
> In that way you are 100% sure that you are not affected by any
> reproducibility or potential new issue.
>
> Berk
>
> _______________________________________________
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://www.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.
>
> --
> This email was Anti Virus checked by Astaro Security Gateway.
> http://www.astaro.com