Start release process of Octave 7.1.0

The release checklist for 7.1 is up at 7.1 Release Checklist - Octave. It would be useful to look through that list and check off items as they are completed using <strike> ... </strike> tags.

For example, I believe updating gnulib has already taken place and can be crossed off in the checklist.

I was thinking more of just the steps needed to do the merge. Looking at what I did, I’m not sure that it would be obvious to someone else exactly what needs to happen.

On the default branch I’ve now updated the NEWS file and removed the functions deprecated in Octave 6. As far as I know, the merge is complete now. I’ll add my notes to etc/ next.

Thank you! :slightly_smiling_face:

I updated the version numbers on the release branch of MXE Octave and merged to default:
mxe-octave: 312b454ec648

@jwe: We can probably merge the default branch to the release branch of MXE Octave whenever you think is a good time for that.

I had a little time and was able to grammarcheck the documentation. I updated the checklist.

1 Like

@jwe: Your buildbots for mxe-octave-stable are failing currently. They are building Octave 7 now. Octave 7 did still build correctly (on your mxe-octave builders) when it was on the default branch.

One of the major differences between the mxe-octave-stable and the mxe-octave builders is that the former builds from the “release” branch of MXE Octave and the latter builds from the “default” branch.

Instead of trying to fix the specific issues on the “release” branch of MXE Octave, could you please just merge the “default” branch to the “release” branch in the MXE Octave repository?
That might cause your mxe-octave-release builders to start failing. But imho that would be ok in the transition period until the first release candidate for Octave 7.

Edit: Kai’s buildbot on that is building Octave 7 using the default branch of MXE Octave did succeed. That suggests that the current issues are probably resolvable by a merge.

Edit 2: I merged the default branch to the release branch of MXE Octave in order to get the CI up and running again while moving towards an Octave 7 release:
mxe-octave: f5bc246da8c3

Like @ttl pointed out here, translation of the GUI shouldn’t start before a string freeze.
When would be a good date for that? Is one week from today enough time to get any changes that might change GUI strings merged to the stable branch? That includes a grammar and spell check of those strings (in case that isn’t done yet).
That means string freeze at 2021-12-06 if nobody minds.

IIUC, the worst-case scenario of changing strings after translations are done is that those strings won’t be translated correctly.

I finished style checking the m-files and C++ (lots of whitespace changes, but nothing functional). I crossed that item off the release checklist at 7.1 Release Checklist - Octave.

1 Like

Just added the last missing function to the Octave manual. The documentation tasks are now finished for the 7.1 release.

1 Like

I have updated the language files and created a bug report for uploading the updated translations. Where should I place the call for the translations. In a separate topic?


I’m not sure if all translators are following the discourse forum. Maybe it would be best to reach out via email like we did in the last years.
A thread on this forum would probably also be good. Maybe you can open a thread here and link to it in an email you send to the maintainers list and all translators?
What do you think?

1 Like

I think that’s a good idea. A lot of translators don’t follow Octave regularly and only respond when asked to make translations for a new release. We keep their e-mails in the libgui/languages/translators file so they can be contacted.

Agreed, I will contact the translators via mail as usual and will open a related thread. I just was confused by the wiki which says that the call for translations is done on discourse.

1 Like

I updated the Wiki page. I’m not sure if it is a good idea to spread out the communication with the translators over three platforms. I think we need the bug report on savannah and the contact via email. Maybe we should skip opening an additional thread here on discourse.
But whatever you decide to do, will probably work for us.

1 Like

@mmuetzel, you are absolutely right. The bug report can already be used for all discussions or questions regarding the translations; no need for an extra thread on discourse.

Is there a specific target date for the 7.1.0 release? The 7.1.0 release checklist still shows 2022-xx-yy for the release candidate and final release in the timeline.

Afaict, there is no definitive target date. IIRC, we talked about trying to get a first release candidate out some time in January or February…

Edit: The most pressing blockers that I’m aware of currently are probably bug #61472, AddressSanitizer crash in MEX tests and the whole visibility thing. The latter with the option to de-activate it for Octave 7 as a fallback.

Edit 2: The most obvious negative side effects of using visibility flags on some platforms are tracked here:
bug #61704, Index vector related tests fail with libc++ when compiled with visibility flags
bug #61711, Test errors for sorting NaN values on Windows with visibility flags

@mmuetzel I commented on the address sanitizer issue. Maybe it is best to disable the visibility flags by default for this release and try to fix the remaining problems so that they can be enabled by default for version 8?

1 Like

Since the actual release of version 7 will almost certainly not happen until 2022, is there any objection to going ahead with updating the copyright year on the stable branch now?


I’m okay with that. Getting rid of the mundane items on the ToDo list for release leaves the mind fresh to concentrate on the real issues.

I disabled the visibility flags by default on the stable branch:
octave: c94757297640 (

They are still enabled by default on the default branch. Maybe, it’ll be in a better shape for Octave 8…