Remaining items for the 6.1 release

Looking at the list of “Octave 6.0.9x release candidates” bug reports here:

I see two regressions that could cause code that previously worked to fail now:

bug #58411: cellfun with “ErrorHandler” returns wrong message

bug #48186: delete(allchild(fig)) in a “deletefcn” callback raises error

and one performance regression

bug #58445: significant slow down in stable version for cellfun invocations which use function handles

It would be good to fix the first two, but I don’t expect to fix the performance issue before the release.

Are any of the rest new regressions for 6.1 or have they always been problems? If not, then I would not expect them to block the 6.1 release.

I also have a possible patch for

bug #59304: exist() does not find a class inside @class directory

but I don’t think this is a regression from 5.2.0, so any fix for it could be delayed until we have time for better testing.


Maybe bug #59375 that I just entered? merely ergonomics admittedly.

I slightly improved the web tool. It fills the table "Octave 6.0.9x release candidates” from the cache of other entries, it should not be slower by more web-requests. Thus if the row is blank, it is probably a not important bug and it should be decided if it is to consider for the release. HTH :slightly_smiling_face:

I think the patch for bug #59304 can be applied. The bug report shouldn’t be closed until exist ('ftp.m') returns 2. But, after the patch is applied I think the release can be changed to “dev” for the remaining issue.

I agree that performance is a secondary concern after correctness so bug #58445 could wait.

I don’t think bug #48186 needs to be solved for this release. The original bug was reported back in 2016. Yes, the issue has re-surfaced in recent versions of Octave, but it is not a very common code pattern so I don’t think it should hold up the rest of the release.

Really, the only one that I think deserves a real look at is bug #58411 where Octave is definitely operating incorrectly, although not so many people use the ErrorHandler feature.

I just filed bug #59401 which might break existing code.

Update on this topic:

  • :white_check_mark: bug #58411: cellfun with “ErrorHandler” returns wrong message
  • :white_check_mark: bug #59304: exist() does not find a class inside @class directory
  • :white_check_mark: bug #59375: [Doc pane] Function index largely dysfunctional
  • :white_check_mark: bug #59401: Automatic variable argn no longer works

Decided to fix later:

  • bug #48186: delete(allchild(fig)) in a “deletefcn” callback raises error
  • bug #58445: significant slow down in stable version for cellfun invocations which use function handles

Still open are:

  • bug #59500: sub-classes of octave_base_value aren’t assignable (Confirmed)
  • bug #59488: eigs error in dsaupd for zero matrix (Works For Me)
  • bug #59426: Horizontal widget positons not persistent (Ready For Test)
  • :exclamation: bug #59432: Octave exits with error code 3 for Bode plot (Need Info)
  • bug #59422: SWIG failure against Octave 6.0 (Need Info)

Of which none seems really relevant except for bug #59432.

Any objections against Thanksgiving release :turkey: of Octave 6.1 (Thursday, November 26)? :smile:

I do agree with everyone that the release is WAY overdue (by about a year :frowning:). Are you suggesting that we make the release now without an additional release candidate for testing?

I think Octave 6 is ready enough and “better” than 5.2, as many many bugs are fixed and users waiting for it :slightly_smiling_face:

There will definitely be another ugly bug lurking in the code to get triggered by a next and a next release candidate. I think it is better to tackle this unknown undetected problem in another minor release beginning of next year :spiral_calendar: If Octave is released more predictable and often, the pressure on a release to be perfect (which is impossible for a software of the complexity as Octave, running on a plentora of platforms) is reduced and user experience and acceptance, living with a problem/workaround for a certain time or even skipping a release, higher.

I’d be glad to start the release process now.


I’m fine with releasing Octave 6.1 right now. There will always be a few things we miss, but that’s what a quick bug fix release is for after 30-60 days.

Recently, this bug showed up when building with Qt 5.15. The horizontal size of docked widgets are not always correctly restored at startup.
I am still trying to find out what causes this and can’t say when a reliable fix might be available. Since is this quite annoying, I just want to let you know.

Should I build with Windows binaries with 5.14?

Yes, if possible. But no test release was build with Qt 5.14, right?

No, but mxe-octave used 5.14.x from January to June this year.

Sounds good. To be sure, let me just backout the recent changeset, from which I thought it would fix the bug for Qt 5.15 but unfortunately does not.

Okay, the cset is backed out.

1 Like

I completely agree that postponing some fixes to a dot-release is a good strategy.
However, changes that could possibly break the API will have to wait for the next version (Octave 7).
I don’t understand completely what was discussed in bug #59422, SWIG failure against Octave 6.0. Is there anything that should be changed in Octave for that bug? And could those changes introduce changes to the API?