[gmx-developers] policy on development on GROMACS branches

[Mark Abraham]

Hi,

Recently I've been asked to make clear our current policy regarding
development branches - particularly old ones. Please ask/discuss as you see
fit.

1. There's a master branch for ongoing development, new features, etc. We
plan to make a new release from it more-or-less yearly. If someone wants a
special-purpose release to conclude some project, then rolling a tarball
and labeling it could happen.

2. There's a current release branch where general bugs get fixed as and
when people (anybody) want to fix them and contribute the fix. Progress on
this branch gets merged to master as applicable. Point releases happen
whenever something serious gets fixed, or semi-regularly (people have
opinions along the lines of "every month or two").

3. Shortly after a new release from master happens, the former release
branch becomes "old."

4. An old branch might get a serious mdrun correctness fix (e.g. as we did
for 4.6.7), but performance tweaking and tools fixing generally won't
happen so please don't push Gerrit commits to those branches, because
reviewing code in old contexts and then merging it is work.

5. There's an unstated period of time after which we won't bother making a
new release from a branch even if there is a back-portable serious mdrun
fix because that's more work than we think is reasonable to do with our
limited resources (e.g. Redmine #1400 is broken in 4.5.x, fixed only since
4.6.6, and won't be back-ported to release-4-5).

The above means that active maintenance of a release branch might last
about 18 months. If it's important for your research to have longer-term
support for the version you choose to use, then you might want to think
about having a line item in your project's budget for paying someone for
the work you might want done. The best way of avoiding this necessity is to
test your simulation setups on non-production work during our beta-testing
phases and let us know about problems while they're fresh.

We also sometimes get the request to avoid making so many releases. We know
that bugs happen, and we think that if they're fixed they should be
released for use. If you (or your cluster system administrators) don't want
to install every version, then please read the release notes and choose to
update accordingly. Not making so releases is not the way to fix the real
problem!

Mark
Gromacs Development Manager
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20140930/591b786f/attachment.html>