[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: release 3.2.1
From: |
Daniel J Sebald |
Subject: |
Re: release 3.2.1 |
Date: |
Fri, 10 Jul 2009 22:56:16 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 |
Soren 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
- Re: release 3.2.1, (continued)
- Re: release 3.2.1, Daniel J Sebald, 2009/07/11
- Re: release 3.2.1, Søren Hauberg, 2009/07/10
- Re: release 3.2.1, Thomas Weber, 2009/07/10
- Re: release 3.2.1, Søren Hauberg, 2009/07/10
- Re: release 3.2.1, Thomas Weber, 2009/07/11
- Re: release 3.2.1, Søren Hauberg, 2009/07/11
- Re: release 3.2.1, Robert T. Short, 2009/07/10
- Re: release 3.2.1, Søren Hauberg, 2009/07/11
- Release process (was release 3.2.1), Robert T. Short, 2009/07/11
- Re: Release process (was release 3.2.1), Tatsuro MATSUOKA, 2009/07/13
- Re: release 3.2.1,
Daniel J Sebald <=
Re: release 3.2.1, Sergei Steshenko, 2009/07/04
Re: release 3.2.1, Riccardo Corradini, 2009/07/07
Re: release 3.2.1, Riccardo Corradini, 2009/07/07