octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Release plans?


From: John W. Eaton
Subject: Release plans?
Date: Tue, 20 Sep 2011 13:52:36 -0400

On  4-Sep-2011, Jordi GutiƩrrez Hermoso wrote:

| I was hoping we could merge in the GUI into Savannah during August,
| but I haven't gotten around to it. I see this as one of the most
| user-visible changes for 3.6. I am hoping we can do it during
| September to have it ready by October.
| 
| I thus propose the following release plan, which I informally already
| communicated in IRC during the sprint:
| 
|     - Release one more bugfix version of the 3.4 series within a month
|       (maybe two, but really aim for one).
| 
|     - Feature freeze on the development branch by October. That means
|       that if you have a particular feature you really want in, you
|       have one more month to finish it. My own wish is that we really
|       get the GUI in there.
| 
|     - After the next 3.4.x release (prepended by an appropriate RC),
|       which hopefully will happen by the beginning of October, we
|       merge default to stable.
| 
|     - Spend the next two or three months stabilising the newly merged
|       in stable branch, making beta RC releases every month or two. If
|       desired, we still implement occasional new features in default,
|       with the understanding that the real goal is to stabilise the
|       stable branch.
| 
|     - Release Octave 3.6 around the December solstice, with a
|       profiler, an experimental GUI (perhaps disabled by default at
|       runtime but enabled at compile time, like we do right now with
|       OpenGL) and the OpenGL plotting enabled by default, all very big
|       user-visible features.
| 
| Part of the goal, I hope, is that we also allow time to catch up to
| binary distributions and we don't announce the release until we are
| pretty sure that binary distributions are all feasible. I'm very happy
| to see Nitnit's work on Windows packaging, and I think it's very
| important to make sure there's a good chance that binary packaging
| will be ready by the time we announce a new major stable release or
| very soon after.
| 
| I know the GUI right now has many problems, but we should work to make
| it part of the next stable release. I will address those in another
| email.
| 
| So how does this sound? Is this a workable plan? Any foreseeable
| limitations?

I'm currently working on a paid project to get some existing Matlab
code working in Octave, so my focus now is on compatibility issues and 
bug fixing.  I don't think I will have time to help work on merging
the GUI within the next few months and I think it would be a mistake
to merge just prior to a release.  So I would like to propose a
slightly less ambitious plan that I hope will allow us to make a good
new stable release and then give the GUI the attention it needs.

  * release 3.4.3 at the end of September or early in October

  * fix as many bugs as possible in the next 6 weeks or so

  * release 3.6.0 by mid November

I can make 3.5.x snapshot tarballs available approximately weekly
until the release happens.

After we merge default to stable (resolving all conflicts by taking
the code from default in favor of those from stable, correct?) then we
can look at merging the GUI on the default branch, early in the
release cycle for the next stable release so that we have plenty of
time to work on it before it is part of a release.

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]