Bugfix list for major releases

In one of the recent monthly meetings, @jwe mentioned that the NEWS should include the bug fixes for N.1.0 and not just for N.2.0 and N.3.0. I made a WIP patch for NEWS.8.md here:
news.patch (12.4 KB)

This was made by taking the output of:

hg log -r dc1347cab668:9d4ef8d54bfe -b default -M | grep "^summary:" | grep -v "doc:"

and then manually deleting lines that were invisible to the end user and most of the repetition. The options restrict it to the default branch, disregarding merges.

The start and end hg id values are the first that started Octave 8 and the last one just before default was merged to stable yesterday:

changeset:   30336:dc1347cab668
user:        John W. Eaton <jwe@octave.org>
date:        Wed Nov 24 07:38:29 2021 -0500
summary:     maint: Bump versions to begin active development of Octave 8.

changeset:   31434:9d4ef8d54bfe
parent:      31432:df8bdaf1164b
parent:      31433:d17ee5e7b66c
user:        Rik <rik@octave.org>
date:        Tue Nov 15 13:13:40 2022 -0800
summary:     maint: merge stable to default

It needs to be cleaned up a lot, and I have not added any documentation changes to it. Please review and help improve it if it looks worth adding to NEWS.8.md.

Unfortunately, I wasn’t there to hear the reasoning behind adding such a list to the NEWS file. But some general remarks to the patch:

  • All sentences should start with an upper-case letter (unless it is a function name or something else that mustn’t change letter case) and end in a full stop ..
  • (bug #xxxxx) should use the same format in all entries. (E.g., all lower case “bug”.)
  • Markdown syntax should be used to mark code segments (like function names or file names).
  • I don’t know how useful it is for an end user to read entries like “bitget.m: Clean up function.” in that list. But like I wrote before - I wasn’t there when this was discussed.

@mmuetzel It was from this meeting https://wiki.octave.org/Online_Developer_Meeting_(2022-09-27) – it’s this part

jwe would prefer 8.1 to also list the bugfixes not just the new features. Bugfixes are listed for point releases like 7.2 but not yet for new releases.

My list was only a starting point and it needs to be pruned a lot. Hadn’t realized there were that many edits until I started on it. It also needs to incorporate the edits to stable after default was merged to stable.

I gathered that it was probably related to that point. But the two sentences don’t go into much detail as to why this should be done. That might give a clue which entries might be useful to include (or not to include).

From what I understand, the reasoning why such a list is compiled for minor releases is that almost any change might be important because it could change the behavior (e.g., some code that previously failed would now run correctly after a bug was fixed). That is important information to pinpoint to in a minor release imho.
In a major release, major changes can be expected. That includes new or removed features, API breakage, …
The most important changes are already covered in the NEWS file. But users would probably need to check if their code still executes the same for major releases anyway. I’m trying to understand which additional useful information we would provide by compiling such a list.

1 Like

My thinking was just that it could be useful for people browsing the NEWS file to see whether a bug they encountered has been fixed.

But compiling a list for major versions at the time the release is made is much more difficult than for minor versions. In some cases, bugs are reported and marked as fixed for problems that were introduced on the development branch and never actually visible in a prior public release. For the list to be useful and accurate, we need to know that the bug was only fixed on default, not a previous stable release, and that it was a problem reported for a public released version of Octave. Probably the only reasonable way to compile a list like that is if we keep it current as bugs are fixed. Maybe that is also not worth the effort.

1 Like

OK I’ll make a small list of preexisting bugs that were only fixed on default – there were definitely some. It won’t be comprehensive but it will at least be short. Since it’s lower priority it might be a couple of days.

I made a new trial patch for the news file for your review:

news.patch (2.0 KB)

I’ve pushed this and also a note about a future breaking change (strings). I pushed it so it could get wider feedback and edits. Pls edit the NEWS.8.md file as needed – if the “bugs fixed” section needs to be removed, that’s OK. The future breaking changes might be more important.

Link: octave: 6544a361e5ca

(EDIT from @rik: This change was pushed to the default branch. Should it be grafted to the stable branch so that it goes out with the 8.1 release?)

Edit: Probably. I won’t be near Octave for the rest of tonight though, so pls move if needed.

Just a note for the future: If you have changes that can clearly be grouped into different topics, even if they are to the same file, please push them as separate commits.
Especially if you are already thinking about partially reverting them.

Edit: also why did you do this change in the default branch?

In your recent change, you added “Octave 8 with long-term support”.
Do you know who will provide the long-term support for that version?
Is there a fork or something else I don’t know about?

I backed out my changes to default from yesterday, split it into multiple changesets and pushed to stable now. Please review for its content.

The “long-term support” phrase was mentioned by @jwe yesterday during the developer call as sounding more marketable, so I adopted that. There was some discussion about whether to backport anything to such an LTS version, and there were no objections raised for that case. (No security concerns since Octave isn’t a setuid executable, etc.) If that situation has changed, I’m OK with removing that phrasing.

I only mentioned that as a possibility if we might someday choose to have a release that breaks a lot of compatibility issues without first deprecating them for a couple of releases as we normally do. I didn’t mean it as something we are actually doing for the 8.1 release. Sorry for the confusion.

1 Like

Oh, sorry for misunderstanding the statement there. I will remove that language and push shortly.

EDIT: Done: https://hg.savannah.gnu.org/hgweb/octave/rev/cb5d5c9d9c14

Is it worth to make the distinction between the string class and double-quotes in the syntax clearer? We’ll probably need to have a string class at least a couple of versions before changing the syntax (i.e., which class double-quotes will produce in the parser).

Edit: That is at least how TheMathworks introduced the string class in their software. And I don’t think we can move faster than their large team of hired developers.

Edit 2: To put that into perspective: If we start shipping a string class with Octave 9 and plan on going at the approximately same pace as TheMathworks, the earliest version for which we should be able to switch the syntax will be Octave 11. That will probably be released in about three years from now.

How about this?

diff -r cb5d5c9d9c14 etc/NEWS.8.md
--- a/etc/NEWS.8.md     Wed Nov 23 05:22:46 2022 -0500
+++ b/etc/NEWS.8.md     Wed Nov 23 06:40:00 2022 -0500
@@ -115,13 +115,15 @@ option to the `print` function.
   to implement a string class, which will differ from a vector of characters.
   Currently in Octave, both 'foo' and "foo" are largely interchangeable,
   barring certain escape sequence interpretations that are present for one but
-  not another.  In future, that is likely to change as a consequence of
-  implementing Matlab-style strings.  This is required for other
-  Matlab-compatibility activities as well.
+  not another.  In a future version of Octave, that is likely to change as a
+  consequence of implementing Matlab-style strings: 'foo' will remain a vector
+  of characters, but "foo" will become a string object.  This change is
+  required for other Matlab-compatibility activities as well.
 
   *What this means for user code*: If you want to treat "foo" as a character
   vector as opposed to a string object, *and* if you intend to use a future
-  version of Octave with string classes, then rewrite "foo" as 'foo'.
+  version of Octave that interprets "foo" as a string object, then rewrite
+  "foo" as 'foo'.  This change will not be immediate.
 
 ### Alphabetical list of new functions added in Octave 8

Slightly modified:

diff -r 88d2395500e7 etc/NEWS.8.md
--- a/etc/NEWS.8.md	Wed Nov 23 08:58:49 2022 -0500
+++ b/etc/NEWS.8.md	Wed Nov 23 15:51:19 2022 +0100
@@ -114,14 +114,18 @@
   Octave should have a Matlab-compatible string class, there is work under way
   to implement a string class, which will differ from a vector of characters.
   Currently in Octave, both 'foo' and "foo" are largely interchangeable,
-  barring certain escape sequence interpretations that are present for one but
-  not another.  In future, that is likely to change as a consequence of
-  implementing Matlab-style strings.  This is required for other
-  Matlab-compatibility activities as well.
+  barring certain escape sequence interpretations that are done for
+  double-quoted character vectors but not for single-quoted character vectors.
+  In a future version of Octave, that is likely to change as a consequence of
+  implementing Matlab-style string syntax: As an example, 'foo' will continue
+  to result in a character vector, but "foo" will result in a string object.
 
-  *What this means for user code*: If you want to treat "foo" as a character
-  vector as opposed to a string object, *and* if you intend to use a future
-  version of Octave with string classes, then rewrite "foo" as 'foo'.
+  *What this means for user code*: If you are using double-quoted strings
+  (e.g., "foo") and rely on them representing character vectors as opposed to
+  string objects, *and* if you intend to update to a future version of Octave
+  in which double-quoted strings will result in string objects, then consider
+  starting to replace all double-quoted strings with single-quoted strings in
+  your code (e.g., replace "foo" with 'foo').
 
 ### Alphabetical list of new functions added in Octave 8
 

Reading this advice: Have we already decided on not using the .oct-config files to support a compatibility flag on a directory basis when it comes to how double-quoted strings will be interpreted?

i think that along with many other specifics of the ‘implement strings’ project still remains undecided. I don’t think there should be anything in this warning that precludes that happening down the line.

Perhaps phrasing like (apologies for not diffing):

Due to many user requests that Octave should have a Matlab-compatible string class, there is work under way to implement a string class that will differ from a vector of characters. Currently in Octave, both ‘foo’ and “foo” are largely interchangeable, barring certain escape sequence interpretations that are done for double-quoted character vectors but not for single-quoted character vectors. In a future version of Octave, that is likely to change as a consequence of implementing Matlab-style string syntax: As an example, ‘foo’ will continue to result in a three-element character vector, but “foo” will result in a single-element string object. The exact implementation of these changes are currently under discussion by the Octave development team, and may or may not include methods of preserving backward compatibility.

*What this means for user code*: If you are currently using double-quoted strings (e.g., “foo”) and rely on them representing character vectors as opposed to string objects, and if you intend to update to a future version of Octave in which double-quoted strings will result in string objects, then consider starting to replace all double-quoted strings with single-quoted strings in your code (e.g., replace “foo” with ‘foo’). This should help minimize any impact of this change on user code as single-quoted strings are not expected to see any user-level behavioral changes from the implementation of string objects.

That seems good to me. We might also try to include the following information (if possible in a clearer and more concise way than I am able to do at the moment):

Full compatibility will also require changing Octave’s behavior for backslash escape sequences in double-quoted strings. Matlab’s single-quoted character arrays and double-quoted strings do not process backslash escape sequences, so '\n' and "\n" both create objects containing two characters (‘\’ and ‘n’, not a single newline character as in many other langauges). Instead of being treated specially when the character arrays are created, functions like fprintf perform backslash escape sequence processing on their format arguments.

In Octave, single-quoted character arrays are currently compatible with Matlab, but double-quoted forms are not. In Octave, "\n" is converted to a single newline character when the character array is parsed.

These changes in backslash escape processing will mean that you’ll also need to change your code if you rely on backslash escape sequence processing in double-quoted strings outside of format strings for functions like fprintf.

We might also point to a wiki page with more detailed info where we could include examples and suggested ways to minimize the pain of transition.

I pushed an expanded version here incorporating all the feedback above: https://hg.savannah.gnu.org/hgweb/octave/rev/8029e9b88950