[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: moving toward a 3.0 release
From: |
David Bateman |
Subject: |
Re: moving toward a 3.0 release |
Date: |
Thu, 28 Sep 2006 00:49:20 +0200 |
User-agent: |
Thunderbird 1.5.0.7 (X11/20060921) |
John W. Eaton wrote:
> On 27-Sep-2006, David Bateman wrote:
>
> | God please don't point the finger at me...
>
> I'm not pointing fingers or asking you to do more. I am saying that
> if people want Octave to improve more rapidly, or have better web
> pages (some progress on this front already, thanks Bill) or whatever,
> that we need more people involved. I don't think I do a great job of
> being the release manager, so I'd be willing to consider having
> someone else (or some group) take on that job. But then you will need
> to be able to merge patches to the release branch of the CVS archive
> to fix important bugs for point releases.
>
> | feedback from Bill and Shai on what they think is needed, set a feature
> | freeze date for octave 3.0 but not at 2.9.9, call 2.9.9 a testing
> | release and the first release after the feature freeze call it 3.0rc1.
>
> My plan was to continue making 2.9.x releases until we decide one is
> ready to be 3.0. I see no reason to change the numbering scheme.
Ok, that'll also work with the version detection in the package manager.
>
> | The only question in the above is when is the feature freeze. Can we
> | just wait for feedback from Bill and Shai before fixing that date?
>
> Sure.
>
> In any case, do we all agree that it would be OK to call 2.9.9 a
> "testing" release? Should we move 2.1.73 to "stable" or just have
> 2.9.9 replace it as the "testing" version? If any annoying bugs show
> up in 2.9.9 we can quickly make another 2.9.x snapshot. I guess I
> would at least like to get the "testing" version closer to what is
> currently the main "development" version.
If we move 2.1.73 to a stable category aren't we in a sense agreeing to
support bug-fixes on it. Whereas, there are some known bugs in 2.1.73
that you've stated you won't fix. Therefore from a practical point of
view probably better just to replace it with a 2.9.9 testing release,
and then there are no false hopes.....
In any case, Soren and I will have to hurry after a 2.9.9 release to get
the new package style octave-forge stuff into place. I don't think its
far off, but there are still some cleanups needed.
D.
- Re: moving toward a 3.0 release, (continued)
- Re: moving toward a 3.0 release, Sebastien Loisel, 2006/09/27
- Re: moving toward a 3.0 release, David Grohmann, 2006/09/28
- Re: moving toward a 3.0 release, John W. Eaton, 2006/09/28
- Re: moving toward a 3.0 release, Tom Holroyd (NIH/NIMH) [E], 2006/09/28
- Re: moving toward a 3.0 release, Bill Denney, 2006/09/29
- Re: moving toward a 3.0 release, David Grohmann, 2006/09/29
- Re: moving toward a 3.0 release, Tom Holroyd (NIH/NIMH) [E], 2006/09/29
- Interpreter performance (was: Re: moving toward a 3.0 release), John W. Eaton, 2006/09/29
- Re: moving toward a 3.0 release, David Bateman, 2006/09/27
- Re: moving toward a 3.0 release, John W. Eaton, 2006/09/27
- Re: moving toward a 3.0 release,
David Bateman <=
- Re: moving toward a 3.0 release, John W. Eaton, 2006/09/27
- Re: moving toward a 3.0 release, Bill Denney, 2006/09/27
- Re: moving toward a 3.0 release, Dmitri A. Sergatskov, 2006/09/27
- Re: moving toward a 3.0 release, Bill Denney, 2006/09/28
- Re: moving toward a 3.0 release, David Bateman, 2006/09/28
- Re: moving toward a 3.0 release, Bill Denney, 2006/09/28
- Re: moving toward a 3.0 release, David Bateman, 2006/09/28
- Re: moving toward a 3.0 release, Quentin Spencer, 2006/09/28
- Re: moving toward a 3.0 release, David Bateman, 2006/09/28
- Re: moving toward a 3.0 release, John W. Eaton, 2006/09/28