looking ahead to 3.6

[John W. Eaton]

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.

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.

  * 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.

  * Make a gtk+OpenGL graphics system.  Or use wxWidgets, or
    something (anything!) that looks better than FLTK (sorry, FLTK
    fans).

Comments?  Additions?

Maybe we should create a page on the wiki for these goals and ideas.

jwe