MXE-octave "default" and "release" branch

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 ftp.gnu.orgalpha.gnu.org 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.

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.