[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #59054] [MXE Octave] Can't build current octav

From: John W. Eaton
Subject: [Octave-bug-tracker] [bug #59054] [MXE Octave] Can't build current octave-stable
Date: Wed, 2 Sep 2020 10:23:07 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Follow-up Comment #1, bug #59054 (project octave):


I propose the following change to the process of handling version numbers
during the time when we are making release candidates:

diff --git a/etc/HACKING.md b/etc/HACKING.md
--- a/etc/HACKING.md
+++ b/etc/HACKING.md
@@ -307,6 +307,7 @@ Since version 5, Octave uses the followi
   5.0.0   (experimental)  active development of Octave 5 on default branch
   5.0.1   (pre-release)   stabilization period of Octave 5 on stable branch
   5.0.90  (pre-release)   first release candidate for 5.1.0
+  5.0.91  (pre-release)   continued stabilization of Octave 5 on stable
   6.0.0   (experimental)  active development of Octave 6 on default branch
   5.1.0   (release)       first release of Octave 5 from stable branch
   5.1.1   (pre-release)   bug fixing on stable branch after 5.1.0 release
@@ -326,7 +327,9 @@ With this numbering scheme:
   * Any version X.Y.Z with Z > 0 means, "this is a pre-release version
     meant for bug fixing and testing".  In practice, Z will be either 1
     (stabilization period after and before making release candidates) or
-    90, 91, etc. (release candidate snapshots leading up to release).
+    90, 92, etc. (release candidate snapshots leading up to release).
+    91, 93, etc. (stabilization period on stable branch during the
+    process of making release candidates).
   * Any version X.Y.0 with Y != 0 means "this is a released version".

This method requires updating the release-octave.mk and stable-octave.mk files
in mxe-octave for each release candidate.

The other alternative I see would be to set the stable branch version back to
X.Y.1 (in the current case, 6.0.1).  Then we would only need to update the
release-octave.mk file for mxe-octave, but it seems bad to me to have the
version number jumping backward after every release candidate snapshot.


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]