MXE-octave "default" and "release" branch

Recent comments on bug #59426 indicate that the problem with widget positions on Windows systems using Qt 5.15 are not fixed. So I intend to build the 6.2 release candidates and release with Qt 5.14.

There have also been many changes to mxe-octave since the 6.1.0 release. I’m not sure whether any of them were to fix bugs or just general updates. So unless someone says that there are some changes necessary to fix bugs, I intend to use the same mxe-octave revision for 6.2.0 as we used for 6.1.0.


I haven’t gone through every change in MXE Octave meticulously. But at least this change was for fixing a hard crash on Windows 32bit:

If I understood @PhilipN’s comment in bug #59426 correctly, the bug didn’t disappear for him when he downgraded to Qt 5.14. So it’s probably caused by something different.

How did you built the Windows versions of dot releases in the past?

In the past, I just used whatever was current in mxe-octave because that was easy to do. But I’m not sure that was the best thing.

I’ve uploaded the first test release and also pushed the changes to the Octave and mxe-octave sources. For now, I’ve created the Windows binaries using the same mxe-octave packages as were used for 6.1.0 but we can change that if needed.

On Windows 10 with the 6.1.90 test release using Qt 5.14, widget positions do appear to be preserved when restarting Octave.

Thank you very much. :+1:
I’ll test them when I come around to it.

If I understood bug #59426 correctly, the general layout is preserved also with Qt 5.15 now. It is only a particular layout (3 columns with particular content?) that slightly changes after a restart (similarly with Qt 5.14 and 5.15).
Please correct me if I misunderstood.

With respect to the revision of MXE Octave to use for the Windows builds: I get your point that it might be preferable if a dot release only differed in the changes made in core Octave. That would be very similar to how distributions fix errors that are found in — let’s say — Ubuntu 20.10. But they usually don’t update to newer software versions until the next major release of the distribution – e.g. in Ubuntu 21.04.

At the moment, we don’t distinguish between bug fixes and updates in MXE Octave.
Maybe we could have a stable and default branch similar to what we have in the Octave repository. That way we could have bug fixes (and maybe Octave Forge package updates) on the stable branch, and updates for packaged software on the default branch.
We could merge default to stable ahead of a major release (similarly to what we do with the Octave repository).
That would require a little more work for maintaining the two branches in MXE Octave.
But if we require that software we ship in the Windows installer stays “constant” during a major release cycle, we’ll probably need to do something along those lines.

I’m still undecided of whether that is really a strong requirement though.

Should we just continue with two heads and graft/apply changes there?
I’m thinking of the fix for bug #59599, an update for README.html, etc.

But that might get confusing if both heads are on the same branch…

Also: The stable-octave and release-octave builders of your buildbot should probably build from this head. But the default-octave builders should build from the other one…

For now, I just merged the version updates back on the main default branch so that the next time the buildbots try to build the release and stable windows versions I think it will work?

But yes, it might be better to create a real named branch for this job and fix the buildbot configuration to use it.

Thinking about it a bit more I believe it might make sense to have different branches for the releases and development versions of Octave in MXE Octave.
Maybe we should just try that. If it turns out that maintaining two branches will be too much of an effort, we could still abandon the new branch or merge the two branches again.

Having written that: I don’t know how to create a new branch with Mercurial. Could someone who knows how to do that please create a new branch “stable” in the MXE Octave repository? It would probably make sense to start that branch from c724e30df2ba as its parent.

We already had inactive “stable” and “release” branches in the mxe-octave repo so I just updated the “release” branch to be the same as the revision that added the octave-rc-6.1.90 tag, then grafted your changeset to fix the URL, then merged that back to default (that just removed the extra head). Now we can apply changes for the released version of Octave for Windows on the release branch and merge them back to default.

I’ll also need to update the buildbot configs. At first, I was thinking that this change would only apply to the release builds, but I guess since stable becomes the new released version, we should also be using the same mxe-octave branch to build stable-octave and release-octave. And then maybe stable would be the better name instead of release. I can still change it to that instead.

Thank you.
I grafted the change for bug #59599 to the re-activated “release” branch, updated the “README.html” file and merged back to default.

It might also make sense to graft the changes that update Octave Forge packages to the re-activated branch. But I don’t know if those required updates of other packages.
I’ll probably just try to build from the re-activated branch after I updated the OF-packages locally and see if they compile and work without new issues.

I don’t think the name of the second branch is very important. I’ll just follow whatever you decide is best.

Shall I switch with my buildbots to the “release” branch (mxe-octave: branches)?

I’m not sure which is the “most appropriate” branch for your buildbots, @siko1056.

On the one hand, they build from the stable branch (which would favor the “release” branch). On the other hand, they are nightly builds of unreleased code bases (which would favor the “default” branch).

It might also be handy if we could point users to a version with more up-to-date packages in case we’d like to have something tested (which would favor the “default” branch again).

But whichever way you decide to go is probably good. Just let us know which option you chose please.

If all future point releases (6.2.0, 6.3.0, …, 7.1.0, 7.2.0, etc.) are built from the “mxe-release” branch, “my nighties” should follow (that is my confusion if this is the case :sweat_smile: ). Then I do not give the false impression something is fixed or updated, that will not be in the official releases one day later :innocent:

I also see your point with delivering more up-to-date packages for testing, but users can in general use the pkg tool for updates, too.

Sorry, I wasn’t more specific. I was referring to packages that we build as part of MXE Octave (like Qt, LLVM, Qhull, mesa3d,…).
I agree that updating Octave Forge packages after installation is feasible. But updating other packages is difficult or impossible.

@jwe: Maybe you could use something similar to the attached patch for the buildbot configuration:

Use different branches for building MXE Octave release and stable or default.

  • master.cfg: Use the “release” branch of the MXE Octave repository to build
    Octave release or stable. Use the “default” branch of the MXE Octave
    repository to build Octave default (or native builds).

mxe-octave-release.patch (8.4 KB)

I also noticed that the no-extras builder configures with SPQR. Maybe we could use this change:
buildbot-no-extras-spqr.patch (939 Bytes)

Above thread was extracted from Plans for Octave 6.2?

Another thread has been opened on Savannah GNU Octave - Bugs: bug #60170, [MXE Octave] Add of-octproj package [Savannah]

I think it is better to keep general discussions here.

I grafted the recent updates of Octave Forge packages to the release branch.
It is probably ok to update Octave Forge packages on the release branch directly and merged the changes to default if possible.
Please, let me know what you think about having those two branches in the MXE Octave repository.

What will be the schedule for merging default branch of everything else to release ? The same time as when octave 7 gets prepped for release ?

Tbh, I haven’t thought this far ahead yet.

IIUC, jwe preferred to not have too many changes in the Windows bundle between dot-releases. I kind of agree that it’d probably make sense to only fix bugs (and update Octave Forge packages) similarly to what we do on Octave’s stable branch.
It might make sense to wait until a major release with other updates that aren’t needed for fixing bugs.

We should probably merge the default to the release branch in the MXE Octave repository some time between just after merging default to stable in the Octave repository (probably the earliest it’d make sense) and just before the first release candidate (probably the latest opportunity).
I’d vote for not waiting too long to have sufficient time for testing.

IIRC, jwe wrote about switching his buildbots to the release branch for the stable and release targets. The default targets on his buildbots would still use the default branch of MXE Octave.

I don’t know what Kai Torben decided to do for his nightly builds. But if he keeps tracking the default branch of MXE Octave, any changes on there would still be tested with the current stable branch of Octave.
In that case, we’d probably have a good enough test coverage on both branches.

What do you think?

Does building stable or default Octave in mxe-octave also differ w.r.t. Octave-Forge package? If so, I never noticed.

FWIW I usually have the very latest fixes for several OF packages in my build, notably the packages I’m using or busy with (io, mapping statistics, signal and linear-algebra).

If I want a stable release Octave for some reason (happens rarely) I just edit the Makefile by hand to change OCTAVE_TARGET.
In the past I kept stable and default versions side by side ( patch #8469 ) but these days I don’t care too much :-), I just renew my mxe build tree every other month.