Re: plans for release

[Richard Campbell]

In the seven weeks since I first asked whether we were ready for a new
release, we've fixed a large number of bugs and made many other
improvements.  There are currently no bugs in the tracker tagged with
"blocker" severity.  So I'd like to make the 3.4.0 release this
weekend if possible.

Perhaps you are thinking, "WAIT!  Is he crazy?  This weekend?  We have
only had two test releases so far.  And they weren't even announced on
the web site!!!  And my favorite bug is still not fixed.  And the
build system is not perfect.  And what about all those functions that
still need better documentation?"

Well, yeah, I know.

But please remember that there is no way we can make any given release
perfect, and it has been more than a year and a half since the last
major stable release (3.2.0).  Look also at the NEWS file to see how
much has happened since then.  I think we will be much better off to
make a 3.4.0 release now rather than delay any longer.  Then we should
focus on fixing only serious bugs for the 3.4.x series while we
continue to make more general improvements in the default branch in
the Mercurial archive, with the idea of shortening the release cycle
in the future (and this time, I mean it! :-).

Don't get me wrong, the improvements of the last few weeks have been
great, but I fear that we are slipping into a cycle of trying to fix
every problem, no matter how small.  If we continue on this path, it
seems we will never have a release because there is an endless supply
of nits to pick.

So, Are there any serious problems that absolutely must be fixed before
a release can happen?  If so, then those problems should be entered in
the bug tracker already, and you can just post a link to them here.

Thanks,

jwe

John,

I'd like to see Jarno's blaswrap.c included in the Octave source, and used automatically when the user runs ./configure for a 64-bit Octave on a machine where the Apple-provided BLAS is the only one detected. Other than that, if these things below are addressed in configure, then a user should be able to walk themselves through building Octave on a vanilla OSX machine without having to dig through this board:

a) -D_REENTRANT appended to CXXFLAGS

b) -ff2c appended to FFLAGS in 32 bit mode (when not using blaswrap.c)

c) --disable-readline implied if GNU readline isn't detected, rather than erroring out

d) --disable-docs implied if ghostscript isn't found, rather than erroring out

e) GNU PCRE required rather than optional

Campbell