Octave 6.4.0 was released about a week ago.
A big thank you to everyone involved who made that release possible!
We were speaking about targeting the end of this year or early next year for the next major release: Octave 7.1.0.
Would anyone still like to push some changes while Octave 7 still rides the default branch?
From the notes of the developer meetings:
Online Developer Meeting (2021-10-26) - Octave
- Symbol visibility breaks tests for indexing expressions on macOS. Also many linker warnings similar to this (see bug #59820):
ld: warning: direct access in function 'conv_to_int_array(Array<octave::idx_vector> const&)' from file 'liboctave/array/.libs/libarray.a(libarray_la-Array-util.o)' to global weak symbol 'vtable for Array<long long>' from file 'liboctave/array/.libs/libarray.a(libarray_la-Array-i.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
- Support paths including spaces (mostly for Windows - not relying on short file names). What about package Makefiles? Probably best if we defer that one to later.
- more efficient mex file interface with direct pointers to data in Octave arrays (jwe)
- Prefer OCTAVE_LOCAL_BUFFER over Array objects where possible (Rik, not a blocker)
Afaict, @jwe already pushed the changes he intended to make.
With regards to the issues with symbol visibility on macOS, it might be best if we disabled the visibility flags by default on that platform. Maybe we could do that only on the stable branch after default was merged to stable. That is unless someone knows how to resolve that.
We already talked about the issues with spaces in paths. We decided to defer that to after Octave 7.1.0:
- For Octave 7, still install to “Program Files” by default. Keep the workaround with conversion to short file names intact for released versions. Remove the conversion to short file names in nightly builds on https://octave.space when the first nightlies of Octave 7 will be built.
- Try to fix those issues where we find them or get reports.
Are there any other projects we should wait for?
IIRC, some of the first tasks when starting a new major release previously were merging the default branch to stable and bumping the gnulib version. (I don’t know in which order.)
I also noticed that some of the autotools macros that we use have been updated upstream in the meantime:
The Macros (Autoconf Archive) (gnu.org)
Would it make sense to get these updated versions?