MXE-octave "default" and "release" branch

i agree with the fix bugs and keep the main changes for major releases, there are perhaps a few packages that updating to the latest version is the bug fix, but as general rule for most thats fine.

I generally build using stable octave, but with the default mxe branch for my testing, but usually only for x86-64

I waited for discussions, decisions and changes to settle, but there still seems to be a need for discussion as it showed up in the recent bug report :thinking:

In general I will switch to “release” too. The scope of my project is not to create another test system (this is kind of a duplication of @jwe 's buildbots), but reliable ready-to-use nightly Octave builds for developers willing to test the future Octave release for their software.

@mmuetzel I totally get your point about the usefulness of building one binary with the mxe “default” branch regularly. As a compromise, I can imagine to switch to “release” in general and to create a new target just building octave-XX-w64.7z and octave-XX-w64-installer.exe from the “default” branch. This would only create another 500 MB and 4 single-worker-hours more per release.

Is it possible to switch the mxe branches, without expensive runs of bootstrap and configure?

Just to make sure we don’t get things mixed up:
While preparing the release of Octave 6.2, an old branch in the MXE Octave repository was re-activated. While the “default” branch is the only one we were using for quite some time, the re-activated “release” branch lags behind with some package updates (I’m referring to all packages, not just Octave Forge packages).
At least right now (and probably always?), you’ll be able to configure and build any of the three Octave targets on both branches. Those are “default-octave”, “stable-octave” and “release-octave”.
In principle, hg branches could differ in many aspects. So, yes, it might be that you’d build different Octave Forge packages depending on which branch you are building from.
But as soon as you selected a branch, it doesn’t matter which Octave target you are building. You’ll end up with the same version of Octave Forge packages.

To sum it up: “branches” and Octave “targets” are different things. The combination of both decides what you are building.

Side note: I’m not sure what you are referring to with “I just edit the Makefile by hand”. But if this means what I think it does, I’m not sure this is a good idea. You’ll end up with an installation mix of two different Octave versions in the same tree. MXE Octave doesn’t even attempt to uninstall a prior version if you just rebuild. (And I don’t think it’ll be possible that one version can cleanly uninstall a different version of Octave.)

Afaict, you can switch branches at any time in principal. I’d also think that you can run the bootstrap script and configure even if you ran those commands on the other branch before in the same tree.

However, if you built some packages (that might differ between the two branches) running make on one branch and then switch to a different branch, you’d probably need to clean the tree and start over. If you don’t, you’d probably end up with a mix where different versions of the same package (not Octave Forge packages in this case) might be installed at the same time. It’d be hard to tell which versions would be picked up when dependers are built (depending on which mechanism they use to find their dependencies). And it might be that different dependers might pick up different versions of the same package. You might end up with packages that are incompatible to each other.

1 Like

Yeah, there might be some edge cases where it could be harder to decide whether it is for a bug fix or “just” an update.
E.g. what about bug fix releases for any of the upstream packages?
Not all upstream packages make bug fix releases for their older releases. They fix bugs in a new release. What for those?

For the moment, I agree that it’ll probably best serve our intentions if we just update on the release branch for bugs that we notice or that get reported to us.

If it should turn out that this isn’t a good approach, we can always adjust.

I mostly build the default-octave target in MXE Octave. And I’ll probably mostly stick to the default branch of MXE Octave for my test builds, too.
IIUC, the buildbots will have the release branch pretty much covered at some point in the future.