Start release process of Octave 7.1.0

I do see “Create Savannah tag 7.0.90 on bug tracker.” is one of the first steps. Looks like that would be a @jwe @rik @mtmiller or @JordiGH thing if the Savannah list is correct.

Then a general post requesting people id bugs that should get that tag, and I guess inclusion discussion could take place there or on the individual bug reports.

1 Like

I created a 7.0.90 tag on Savannah for RC1 of release 7.1.

1 Like

i haven’t hunted up the conversation, but there was some work a short time ago on removing the need to call a vbs file to launch octave on windows, going back to just calling octave.bat or similar. Did that ever go anywhere? The inspiration was the periodically encountered windows user unable to execute vbs scripts due to configuration or security settings. I thought it seemed to be a likely change, but don’t recall the status. It would be a nice thing to move past for v7.

Does the vbs script do anything other than set some environment variables and then execute octave-gui.exe? Could we replace the vbs script with octave.exe (the program built from src/main.in.cc) instead? If you use octave.exe on Windows, it processes some options then executes either octave-cli.exe or octave-gui.exe. So it seems we would just need to make it set the environment variables that are currently set in the vbs script before it calls exec.

trying to dig out the conversation that went through the why’s for octave.vbs vs bat, i believe it answered those questions. Honestly, I think I remember it coming down to " vbs doesn’t leave a command window open in the background while bat does," and didn’t touch on why it couldn’t be done directly by the .exe. i think it was on the mailing lists.

here’s the thread:
https://lists.gnu.org/archive/html/octave-maintainers/2020-08/msg00008.html

started a new topic for discussion of this vs derailing this post. (worth noting you suggested a separate exe ‘octave launcher’ and c code for one was provided by JohnD but don’t think it went anywhere. Also didn’t see a focused bug report for this if that’s where it should go.

see: Windows startup - vbs, bat, or exec?

1 Like

Is it worth waiting much longer with merging default to stable?

In the initial phase of getting Octave 7 ready for release, we could still push new features to the stable branch for a while.
The motivation to fix anything on the stable branch (that is already fixed on default) is pretty low because there probably won’t be any more Octave 6.x releases.
On the other hand, more disruptive changes are already held back because we are already in a phase where we don’t want to de-stabilize the sources on the current default branch too much. (Or is this a wrong assumption?)

What do you think?

I intended to refactor the way function objects are stored in the octave_value class hierarchy before the release. But looking at it again today, I think the changes are too much to do now, just prior to the release. So I have no objection to merging default to stable now and going ahead with the release.

Sorry. I didn’t want to rush anything. If you’d like to get some change in while Octave 7 is still on default, that’s more than ok.
If you’d like to defer those changes to Octave 8, that’s also fine.

Anyway, given my past of accidentally leaving the repo in an inconsistent state, I’d very much appreciate if you could do the merging at your discretion.

In preparation for that, I updated gnulib to the latest revision here:
octave: 5ea881d55465 (gnu.org)

I think I delayed working on the function object refactoring too long and the changes will be too big and disruptive. I don’t want to delay the release for these changes but instead work on them early in the version 8 development cycle. Unless there are objections I can merge the release sometime tomorrow or over the weekend.

2 Likes

Besides reviewing the open bugs on Savannah to see if they have already been fixed, it would be nice to look at the ones marked “Ready for Test”. I just checked and there are 15 such bugs. Probably the fix is good and those bug reports can be closed.

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.