Start release process of Octave 7.1.0

Are we still on schedule? What happens after merge of default on to stable? Is it then just final bug fixing on stable branch before release?

I’m thinking of a widespread documentation change to always document when a function returns a value. This is implicit and most core programmers never think about it, but it catches newbies. As an example, current documentation for sind begins

-- sind (X)

but would become

-- Y = sind (X)

Since this is just documentation I believe it can happen either on dev or stable branch.

2 Likes

If you make these changes before I merge default to stable, go ahead and make them on default. If you don’t get to it before the merge, it can be done on stable and merged back to default.

As discussed during the developer meeting yesterday, I merged stable to default to start the release process. Then I also merged stable back to default and updated version numbers on default to begin the active development period for Octave 8. Next, I’ll do the following:

  • update the build rules for mxe-octave
  • make any changes needed to the buildbot configurations

On the default branch:

  • remove functions and properties deprecated in version 6
  • update the NEWS file for version 8

Is there anything else? I’m making a record of these steps and will add them to the etc/HACKING.md file.

2 Likes

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/HACKING.md 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 octave.space 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?

2 Likes

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