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?

IF we were to fix anything for that bug report, we would just be adding some functions and typedefs, so I think it would be OK. But even if we do add those, they will not fix all of the problems reported there because there were some structural changes to Octave internals that made it impossible to preserve some interfaces that were used by SWIG.

The OP reported back on bug #59422 and everyone agrees that it is clearly no Octave issue that the software module of SWIG relies deeply on Octave internals.

@jwe Did the release process start? :slightly_smiling_face:

Yes, it took some time for me to build the Windows binaries. I expect everything will be uploaded later today and we can announce tomorrow once there has been time for the files to make it out to the mirror sites.

1 Like