[torquedev] Torque release protocol

Garrick Staples garrick at usc.edu
Wed Jul 21 02:04:11 MDT 2010

On Jul 21, 2010, at 12:24 AM, Christopher Samuel wrote:

> 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.

That would be easy. As soon as Ken said that 2.5 was coming soon, I think the feature-freeze pretty much happened anyways.

> 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:

Sounds like a pipe-dream. But if CRI could do it, that would be great.

> 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 :-(

I love it.

> 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.

Bah. We had a "blessed" beta release. It got the testing that it was going to get.

> 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!

I personally dislike anything that differs from x.y.z. Any extra letters just get in the way.

Can't we just throw out 2.5.0, tell people that it is new, get back fixes, and release 2.5.1?

> 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.

I was quite suprised that this happened. It really shouldn't.

> 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.

Why not? Because noone cares. Noone ever goes back and looks to see what was in 2.3.232.  If you want to know, untar the old tarball that I know you have sitting around and look. Though, if it would discourage overwrite tarballs, I'm all for it.

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

Let's not overprocess ourselves. Sometimes mistakes happen and we just need to fix it, move on, and not blame the "process."  Developing is supposed to be fun. Lots of procedural overhead is not fun.

My process is pretty much limited to this:

development is done in trunk or feature branches.  'make distcheck' often.
For a new release, copy trunk to new fixes branch.
Trunk's version is immediately incremented in configure.ac, regen files, commit.
cd x.y-fixes
'make dist' in new fixes branch and copy tarball to web server
Immediately increment version in configure.ac, regen files, commit.

More information about the torquedev mailing list