Re: Release Plans

[John W. Eaton]

Way back in April, I posted the following list of goals for the next
release with a target date of sometime in June (see below for the
list).  I guess we slipped a bit on that target date...

So, is it essential that we have the rest of the items completed
before the release?  The two issues on my list that have not been
fixed are

  * Proper handling of 64-bit indices for binary load and save
    formats.  Not very many people need or use 64-bit indexing, so
    I think this can be delayed without causing much trouble.

  * Integrating QtHandles with Octave (I started, but did not finish
    that job yet).  It would be better to use Qt for all GUI objects,
    but we are still using gnuplot by default, right?  So maybe this
    item could also be delayed.

So I guess the big question is whether it would be better to

  1. release the GUI as it is now with gnuplot graphics still used by
     default and then work toward another stable release in about 6
     months that uses Qt widgets for the graphics windows and OpenGL
     graphics by default,

or

  2. further delay the release until we have OpenGL graphics + Qt
     widgets working as well as the current OpenGL graphics + FLTK
     widgets?

I'm leaning toward the first option but I'd like to know what other
people think.

In any case, I think most of these are done now and the GUI (and
really all of Octave) is looking a lot better now than it did when I
first started talking about the release back in April.  About 2800
changesets have been applied to the default branch since we branched
for the 3.6.x release series back in December 2011.  That represents a
tremendous amount of work.  Thanks to everyone who has made Octave
better during this time.

jwe

>    * A working GUI enabled by default
>
>      - Most necessary features are implemented.  The focus now needs to
>        be more on fixing problems with the features that are implemented
>        and less on adding more features.
>
>      - QtHandles.  It would be nice to have the windows that wrap the
>
>      - uigetfile.  We have a version that uses FLTK.  We should have one
>        that uses Qt to match the rest of the GUI dialog functions.
>
>    * Improved performance for fread and fwrite, at least for common cases
>      when no data conversion is required.  I've done some work on this
>      job, but it needs to be finished.
>
>    * There are some problems that need to be addressed to improve support
>      for 64-bit indexing.
>
>      - We use "long int" to pass 64-bit index values to HDF5 routines and
>        that fails on Windows becuase "long int" is 32-bits wide.
>
>      - We need to revise Octave's binary file format so that it can save
>        dimensions as 64-bit quantities.
>
>    * Release with Java enabled by default.  The JVM is not loaded
>      unless it is needed, so having Java enabled by default should not
>      cause trouble for users unless they actually want to try using
>      some Java functions.  The only exception is that the dialog
>      functions attempt to use Java if the Qt versions are not
>      available, but I think that will be a tiny minority of users.
>
>    * Release with the JIT compiler disabled by default.  The JIT
>      compiler does not currently compile very many things but a bug in
>      the way it compiles and executes a loop would be bad for many
>      users.  I also don't think it has had the testing it needs to be
>      considered ready for release.