[gmx-developers] Gromacs 4.0.5 released?

[hessb at mpip-mainz.mpg.de]

> 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