Re: looking ahead to 3.6

[Kai Habel]

 On 11.02.2011 21:16, John W. Eaton wrote:
> I know, we just barely have 3.4 out there, but I'd like to take a look
> at what should be done for 3.6.
>
> First, I'd like to continue to try to shorten the release cycle.
> We've made some progress since the no release :
>
>    1.0: Feb 17 1994
>    1.1: Jan 12 1995  11 months!  Things were simpler back then...
>    2.0: Dec 10 1996  23 months
>    2.1: long series of widely used snapshots but no "stable" releases
>    3.0: Dec 21 2007  ???
>    3.2: Jun  5 2009  18 months
>    3.4: Feb  8 2011  20 months
>
> My goal is to cut the time between releases to 9-12 months, so that
> would mean starting the release process sometime in september this
> year.  If the release cycle is much longer than a year, then it seems
> to become difficult to make releases.  If they happen more frequently,
> maybe we won't pressure ourselves into trying for last minute
> perfection.
I few comments from my side.

Maybe it makes sense to have a more fixed release schedule for each year.

* First-Half of the Year: Inclusion window for large Projects
* ...
* Branch for next release: Mid-October
...
* Release: First Week of December


> Next, I have a few projects that I would personally like to work on
> (these might not all happen for 3.6, but they are things I'm currently
> most interested in):
>
>    * Improve textscan.  I promised Ben Abbott that I would look at what
>      is needed to handle the textscan-specific format specifiers.  I
>      started doing that, but never finished the job.
>
>    * Look at whether octave_idx_type should be an unsigned type.  See
>      
> https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2011-February/022980.html
>      for some motivation for a change like this.
>
>    * Fix lsode, dassl, daspk, etc. to accept an options structure
>      as an argument instead of using a global option structure
>      (losde_options, dassl_options, etc.).  If possible, this should be
>      done in a way that allows a smooth transition, so that code using
>      the *_options functions can be deprecated but will continue to
>      work for at least one release cycle.
>
>    * Make the current FLTK+OpenGL plotting system work better so that
>      we can make it the default.  For this to happen, there are a lot
>      of little bugs that need to be fixed, plus we need to make
>      printing reliable.  If possible, we need to make printing work
>      even when a plot is not displayed on the screen.
My plan is to look at the fltk problems reported at the bug tracker 
soon. (Fixing bug#32040 takes longer than expected.)
>    * Integrate a GUI with the core Octave distribution.  My preference
>      would be to start with OctaveDE since I think it is doing the
>      right thing by embedding Octave rather than communicating with
>      Octave using pipes.  I'm willing to consider other alternatives,
>      but it is important to me that we have a way to interact with
>      Octave's command line without needing to completely reinvent
>      readline.
I fully agree.
>    * Make a gtk+OpenGL graphics system.  Or use wxWidgets, or
>      something (anything!) that looks better than FLTK (sorry, FLTK
>      fans).
Yust for the record: I am not a fltk fan either ;-), but it is 
relatively easy to use.
Whatever we choose, it should work on the three major platforms (Linux, 
Windows, Mac) reasonably well.

Kai