<div dir="ltr">Hi,<div><br></div><div>Recently I&#39;ve been asked to make clear our current policy regarding development branches - particularly old ones. Please ask/discuss as you see fit.</div><div><br></div><div>1. There&#39;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.</div><div><br></div><div>2. There&#39;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 &quot;every month or two&quot;).</div><div><br></div><div>3. Shortly after a new release from master happens, the former release branch becomes &quot;old.&quot;</div><div><br></div><div>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&#39;t happen so please don&#39;t push Gerrit commits to those branches, because reviewing code in old contexts and then merging it is work.</div><div><br></div><div>5. There&#39;s an unstated period of time after which we won&#39;t bother making a new release from a branch even if there is a back-portable serious mdrun fix because that&#39;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&#39;t be back-ported to release-4-5).</div><div><br></div><div>The above means that active maintenance of a release branch might last about 18 months. If it&#39;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&#39;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&#39;re fresh.</div><div><br></div><div>We also sometimes get the request to avoid making so many releases. We know that bugs happen, and we think that if they&#39;re fixed they should be released for use. If you (or your cluster system administrators) don&#39;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!</div><div><br></div><div>Mark</div><div>Gromacs Development Manager</div></div>