Re: 3.2.x

[John W. Eaton]

On 23-Sep-2008, Michael Goffioul wrote:

| As a user, I would expect a (kind of) *major* release of octave such
| as 3.2 to bring some outstanding changes or new features. I would
| also expect those features to be quite complete.

That would be best, but I'm just saying that I don't think it is
necessary to have everything perfect for a release.  If we require
that, then we will never have releases.

| OO support is a
| good candidate for this, but it still lacks a few things to make it fully
| usable (like operator overloading). So I'd see the completion of OO
| support as a requirement for 3.2 forking.

The OO features that are present now are sufficient for the people who
supported the work.  So far, I haven't seen a lot of people trying to
use the new features and telling us that they are incomplete.

In any case, operator overloading does work, at least for user-defined
types.  What does not work is overloading operations for built-in
types, and we have not decided what to do about these operations in
relation to constant folding in the parser.  If anyone is interested
in the issues, then I think we should start a separate thread for that
discussion.

| I hoped to see the graphics stuff also fully functional for the 3.2
| release, but given the manpower and the current changes in my private
| life (don't worry, only good news, but time-consuming), I don't see it
| as a realistic target. My target is 3.4, with 3.2 being a technology
| preview.

I have no problem with including the new graphics code but keeping
gnuplot as the default backend.

| OTOH, I see 3.0.x releases as bug-fixes only release. You can't
| expect new features there. If some changes from the main branch
| cannot be transplanted easily, then I'd say "Too bad, but that's the
| way it is, just wait for the next major release". If some changes would
| still be useful for the 3.0.x branch, then you can ask the patch author
| to port it to the stable branch (instead of you having to do the whole
| work).

We have been pretty liberal with the changes to the stable version.
We sometimes include new features, fixes to documentation, and fixes
to bugs that have existed for a long time (i.e., not regressions from
something that used to work properly in previous versions of Octave).
It would be entirely reasonable to only fix regressions, as for
example is done for stable GCC releases.  Taking that approach also
tends to minimize the work required to handle patches for the stable
release.  But if we decide to go that route, I think we'll need to try
harder to have regular releases from the main development branch.

jwe