[torquedev] Torque release protocol

Christopher Samuel samuel at unimelb.edu.au
Wed Jul 21 01:24:20 MDT 2010

Hash: SHA1

Hi folks,

Having seen how the 2.5.0 release has gone I was wondering
about a release protocol to follow for future releases to
try and both capture what went well this time and to guard
against some of the problems we ran into.

These are suggestions for discussion, feel free to chime in!

0. Feature and documentation freezes

One thing would be handy would be to have a period before a
release where we've declared that no new features are going
in and then it's just bug fixes and documentation that can
be changed.

I really liked Garricks method of labelling features in the
Torque source as undocumented (the known unknowns) so there
is a target to go over, and the brushing up of the release
notes and the cygwin readme were also high points.

1. Nightly snapshots & builds

The Open-MPI project has a build daemon that creates nightly
snapshots and does a simple build test, it either generates
an email saying things like:

- ------------------------------------------------------------

Creating nightly hwloc snapshot SVN tarball was a success.

Snapshot:   hwloc 1.0.2rc3r2347
Start time: Tue Jul 20 21:01:02 EDT 2010
End time:   Tue Jul 20 21:03:01 EDT 2010

Your friendly daemon,

- ------------------------------------------------------------


- ------------------------------------------------------------

ERROR: Command returned a non-zero exist status (trunk):
       make distcheck

Start time: Thu Jul 15 21:01:02 EDT 2010
End time:   Thu Jul 15 21:02:49 EDT 2010

[last lines of the results of the make distcheck]

- ------------------------------------------------------------

I think it's very handy for picking up issues early, as well
as giving testers a good place to pick up the latest code from.

I would not suggest that we go as far as people like VMWare who
used to tweet who committed a change which broke the build.. ;-)

http://twitter.com/vmwarepbs  <- much more boring now :-(

2. A number of beta releases.

We went straight from having one beta release on the
2nd July to having the final release with nothing in between.
This makes it harder for users to do testing or even just a
quick "make distcheck" for us as they'll need to know to do
an svn export to grab a copy first.

Nightly snapshots helps a little, but it's good to have
a "blessed" beta that people can report against.

3. Produce release candidates!

Once we think beta is over then we should produce a release
candidate as a sanity test for final changes. If nobody reports
any problems after a week then that same code (with version
number and directory name tweak) gets released as the actual
release version.  If problems are found then a new RC should
be rolled with the changes and repeat the process.

Might also be good to have a list of target architectures
for that release that make distcheck has to pass on before
they RC goes out as the real one.

To echo what Ken and David said it was great to see so
many folks pitch in with that testing!

4. Always increment version numbers for a new tarball.

Even (as just happened) if it's not a change that would be
reflected in the source tree (other than a changelog entry)
it's good practice to do this so people know that something
has changed.

5. Tagging releases (including betas and RC's).

Currently (unless I'm missing something) we're not
tagging releases in SVN, it would be handy to do so
just so we do have an unambiguous way of knowing what
was in the release.

In my project I tag first, then svn export that
tag and roll the tarball from that.

Anyway, just some thoughts on how we can improve
things - any comments ?

- -- 
 Christopher Samuel - Senior Systems Administrator
 VLSCI - Victorian Life Sciences Computational Initiative
 Email: samuel at unimelb.edu.au Phone: +61 (0)3 903 55545

Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the torquedev mailing list