Plans for Octave 6.2?

maintainers
#1

If I recall correctly, when we planned to release Octave 6.1, we aimed to follow up with a bug fix release not too much later. Is that still the plan?
Octave 6.1 was released approx. 6 weeks ago. That is still quite recently, imho.
Nevertheless, some important bugs have already been fixed in the meantime (among which some that prevent correct package execution).
Are there any plans for when that bug fix release should happen more or less?

Other bugs that caused regressions from previous versions are still open. Imho, it would be nice if we could fix those before a bug fix release.
Would it make sense to try and collect some bugs already that should be fixed for an Octave 6.2? Or would it be better to wait and see if more reports will trickle in?

1 Like
MXE-octave "default" and "release" branch
#2

Yes, a 6.2.0 release should happen relatively soon. Fixing any regressions we can is also a good goal. But even if we can’t fix them all, I think it would still be good to release 6.2.0 within a few weeks.

1 Like
#3

There are only a few reports I can think of off-hand that would be nice to have fixed before Octave 6.2 imho:

Any others?

#4

IIRC, we had to downgrade to an older Qt version for some reason.
Is that already resolved? Or is that also something that would be good to have fixed for Octave 6.2? (Or for Octave 7?)

#5

Bug #59704 has been fixed in the meantime. But a new regression has been reported.
That makes the following list of reports which should probably be blockers for Octave 6.2:

#6

This one got fixed yesterday.

This isn’t a regression (as you noted). It should get fixed, but I don’t think it needs to gate a 6.2 release. Someone did provide a potential solution though, so it could be easy for someone who understands the C++ classdef code to verify whether this is an okay fix.

This one also got fixed.

#7

This seems to be the only bug left to resolve.

#8

I just posted a possible fix, but my current patch introduces a change in public interfaces. I have an idea about how we might avoid that, but it would be even less efficient to push a stack frame. I’ll add another comment to the bug report shortly.

#9

jwe’s patch resolves bug #59847, so I think we’re ready to go on a new release unless. I might look at tackling NA in the configure script on ARM architectures, but that is pretty niche.

#10

Should we check again how Octave behaves with Qt 5.15? What was the reason we downgraded MXE Octave to Qt 5.14 for the release?

#11

The bug that prompted going back to 5.14 was: GNU Octave - Bugs: bug #59426, Horizontal widget positons not... [Savannah]

See also: Remaining items for the 6.1 release - #12 by ttl

#12

Are we ready to make the 6.2 release this week? If so I can start working on a release candidate sometime today or tomorrow.

1 Like
Crash when doc of packages functions or typo
#13

I’m not aware of major bugs that should block a new dot-release.
I still don’t know if we can build with Qt 5.15 now. But that might not be a reason to delay a release candidate.
Maybe just go ahead and build with Qt 5.15. What’s the worst that could happen… :man_shrugging:

#14

OK, I’ve been delayed by a few things but I will try to make a release candidate tomorrow and build binaries for 64-bit Windows, at least.

1 Like
#15

15 posts were split to a new topic: Mxe-octave “default” and “release” branch

#19

I downloaded the installer from ftp://alpha.gnu.org/gnu/octave/ and ran the test suite after installing in the default location.
All tests passed with no unexpected errors.

I also ran the tests for all bundled packages. Some are failing. But none of the errors look like regressions in core Octave to me.
I opened new reports for errors I couldn’t find on savannah.

Just to be sure: You used this revision of MXE Octave to build the release?
mxe-octave: a1004ea5643d

#21

I used this mxe-octave revision:

https://hg.octave.org/mxe-octave/rev/f062783e4ace

It is tagged now. But other than version number differences, yes, it should be the same as the one for 6.1.0.

#31

I tested the updated versions of of-ga and of-windows on the new release branch. I didn’t see any issues. So I grafted those changes to the release branch and merged them back to default.
I also grafted the updates of of-nan, of-struct, of-optim, of-fuzzy-logic-toolkit to the release branch and merged them back. I haven’t tested those changes on the release branch yet. But I think I was overly cautious before: If the packages don’t have any (non-Octave Forge) dependencies, it is probably save to update them on both branches if they work on one of them.

1 Like
#32

Should we make another test release? Or is it OK to just go ahead with the 6.2.0 release?

#33

My vote: just release it. There are a lot of improvements over 6.1, and we won’t actually get very wide testing with the release candidates. Only way to really uncover bugs is to have a lot of eyes and that requires an actual release and incorporating in to distros.

1 Like