Start release process of Octave 7.1.0

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

Unfinished projects:

  • 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 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?

@siko1056 already created a 7.1 Release Checklist on the wiki that we can use to help remembering the necessary steps. Thank you for that.

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) (
Would it make sense to get these updated versions?

1 Like

I agree that updating autoconf macros before the release.

I have a few other changes I’d like to get in before 7.x but I won’t hold up the release for them if I’m unable to commit them in the next 2-3 weeks. How about merging default to stable at the beginning of December?

1 Like

Far from essential but could memoize and MException be considered for inclusion in Octave 7.1?

seems neither has been prepared as a patch yet against the current default branch for people to evaluate and test the implementation. are you able to do that? the MExeception bug has been hanging about since 2013 with some code porting compatibility complaints, so might be a nice one to have.

In the past the status page has included lists, or links to lists of bug/patch reports to go through a triage to determine if any are needed, but also if any others are close enough to warrant a little focus to get them across the finish line. I’m not sure if the has a good sharable way of collecting those vs the checklist approach in the past. I’ve tried to use that page to go through bugs with ‘patch submitted’, or to try to find those that should be listed as ‘patch submitted’, or had m-files and just needed a diff made, etc. depending how the search is run, there’s somewhere between 50-500 of those. We had an ‘easy close’ page a couple months ago, should something similar be made on that page and people can add/annotate accordingly?

Of course pure bug fixes can always get pushed to stable and worked into an incremental release later, but seems any new features will be a year away if they don’t make the cut this time.

Things maybe be worthwhile but not too onerous would be new function adds that don’t affect too many other features (usually just m-file adds) and extended compatibility adds (support more or new options, etc.).

patch #10102 (GNU Octave - Patches: patch #10102, [octave forge] (statistics) Add... [Savannah]) contains two candidate functions for inclusion in core: ismissing.m and rmmissing.m.
These are core Matlab functions as of r2013a.
Any opinion from core devs about these functions? or should they rather go into the statistics package? IMO their use case is broader than just statistics.

If a Savannah admin introduces an Octave 7 release tag. GNU Octave - Savannah Bugs and Patches is ready to go and displays bugs always updated in a list :wink:

Merging the upstream changes into our macros was pretty straight forward.
Pushed here:

However, our octave_blas_f77_func.m4 deviated notably from the upstream version (ax_blas_f77_func). I can hardly read any Fortran. So, I don’t think I’m up for the task of merging these files.
Could someone else please check how to merge the upstream changes into our version of the macro?
Would it make sense to try and get our changes upstreamed? Or are these changes too Octave-specific?

1 Like

I have a patch for gsvd which I want to get in to the 7.1 release. I’m finalizing the BIST tests now and should be able to check it in within the next week or so.


I do see “Create Savannah tag 7.0.90 on bug tracker.” is one of the first steps. Looks like that would be a @jwe @rik @mtmiller or @JordiGH thing if the Savannah list is correct.

Then a general post requesting people id bugs that should get that tag, and I guess inclusion discussion could take place there or on the individual bug reports.

1 Like

I created a 7.0.90 tag on Savannah for RC1 of release 7.1.

1 Like

i haven’t hunted up the conversation, but there was some work a short time ago on removing the need to call a vbs file to launch octave on windows, going back to just calling octave.bat or similar. Did that ever go anywhere? The inspiration was the periodically encountered windows user unable to execute vbs scripts due to configuration or security settings. I thought it seemed to be a likely change, but don’t recall the status. It would be a nice thing to move past for v7.

Does the vbs script do anything other than set some environment variables and then execute octave-gui.exe? Could we replace the vbs script with octave.exe (the program built from src/ instead? If you use octave.exe on Windows, it processes some options then executes either octave-cli.exe or octave-gui.exe. So it seems we would just need to make it set the environment variables that are currently set in the vbs script before it calls exec.

trying to dig out the conversation that went through the why’s for octave.vbs vs bat, i believe it answered those questions. Honestly, I think I remember it coming down to " vbs doesn’t leave a command window open in the background while bat does," and didn’t touch on why it couldn’t be done directly by the .exe. i think it was on the mailing lists.

here’s the thread:

started a new topic for discussion of this vs derailing this post. (worth noting you suggested a separate exe ‘octave launcher’ and c code for one was provided by JohnD but don’t think it went anywhere. Also didn’t see a focused bug report for this if that’s where it should go.

see: Windows startup - vbs, bat, or exec?

1 Like

Is it worth waiting much longer with merging default to stable?

In the initial phase of getting Octave 7 ready for release, we could still push new features to the stable branch for a while.
The motivation to fix anything on the stable branch (that is already fixed on default) is pretty low because there probably won’t be any more Octave 6.x releases.
On the other hand, more disruptive changes are already held back because we are already in a phase where we don’t want to de-stabilize the sources on the current default branch too much. (Or is this a wrong assumption?)

What do you think?

I intended to refactor the way function objects are stored in the octave_value class hierarchy before the release. But looking at it again today, I think the changes are too much to do now, just prior to the release. So I have no objection to merging default to stable now and going ahead with the release.

Sorry. I didn’t want to rush anything. If you’d like to get some change in while Octave 7 is still on default, that’s more than ok.
If you’d like to defer those changes to Octave 8, that’s also fine.

Anyway, given my past of accidentally leaving the repo in an inconsistent state, I’d very much appreciate if you could do the merging at your discretion.

In preparation for that, I updated gnulib to the latest revision here:
octave: 5ea881d55465 (

I think I delayed working on the function object refactoring too long and the changes will be too big and disruptive. I don’t want to delay the release for these changes but instead work on them early in the version 8 development cycle. Unless there are objections I can merge the release sometime tomorrow or over the weekend.


Besides reviewing the open bugs on Savannah to see if they have already been fixed, it would be nice to look at the ones marked “Ready for Test”. I just checked and there are 15 such bugs. Probably the fix is good and those bug reports can be closed.