release 3.2.1

[Daniel J Sebald]

Søren Hauberg wrote:
> tor, 09 07 2009 kl. 14:14 -0700, skrev Robert T. Short:
> 
>>Is there to be no comment on this at all?  Both Daniel and I have made 
>>the same comments for the same reasons and probably because we have both 
>>experienced problems like this before.  It isn't that Jaroslav is doing 
>>a bad job, but rather that the process (or rather lack of process) is 
>>guaranteed to have significant problems.
> 
> 
> Well, I agree that Jaroslav is _not_ doing a bad job. Release management
> is just surprisingly hard (I've managed to screw up every single
> Octave-Forge release I've ever made...).

That's what I'm assuming.


> I haven't commented on the suggestions related to how to fix this, as it
> seems like what is being asked for is more man-power. Basically, we need
> a set of beta testers that are willing to use release candidates for a
> couple of months before that final release is made. The big problem with
> this is that currently when a new release is branched, development still
> goes on in the main branch. Personally, I tend to run a version that is
> a recent checkout from the main branch, so I qualify for being a beta
> tester. However, if development is going on in the main branch, then I'd
> prefer to run that rather than the soon-to-be-released-beta-branch. I
> mean, if I'm gonna run development versions, then I might as well live
> on the bleeding edge, right?

Bleeding edge is good (and fun), but as Octave has gained features I've become content to be slightly behind bleeding edge.  I'd be alright working with a release candidate for a month or two.  As someone else pointed out, a modest group of people using the software is fine as a "beta" test.  People tend to have slight variation in programming styles that might challenge what the original programmer may have overlooked.


> Anyway, my point is just that to improve release quality, we need more
> testers. We actually have a bunch of such testers, but they all tend to
> run the latest development version rather than the latest release
> candidate. The only solution I see (as long as we don't have more
> man-power), is to only have one branch of development.

I'm tending to agree with that.

Seeing the drop in activity over the past half month, I think that a good release schedule for major releases would be to work toward a candidate version near the end of May or mid June.  Hold off cutting edge features in summer when activity drops due to vacation/holiday, concentrating instead on bug fixes.  How about the major release mid to late August?  With Mercurial's capabilities, I'm understanding that people can queue up their changes for a few weeks.  After the release, there'll be a flood of change sets.

Dan