Change version numbering scheme?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Change version numbering scheme?

John W. Eaton
Administrator
I propose that we begin using a version numbering system similar to what
is now used by GCC (https://gcc.gnu.org/develop.html):


Starting with GCC 5 we will bump the major version number for each
release. The version number and DEV-PHASE will develop in the following
way and on the following timeline:

Version DEV-PHASE When

5.0.0 (experimental) during active development of GCC 5 (stage 1-3)
5.0.1 (prerelease) during the stabilization period of GCC 5
6.0.0 (experimental) during active development of GCC 6 (stage 1-3)
5.1.0 for the first release from the GCC 5 branch
5.1.1 during development on the branch post the 5.1.0 release
5.2.0 for the second release from the GCC 5 branch
5.2.1 during development on the branch post the 5.2.0 release
6.0.1 (prerelease) during the stabilization period of GCC 6
...

To summarize, the first release of GCC 5 will be GCC 5.1.0 while
development snapshots will be GCC 5.0.0 and snapshots from the release
branch GCC 5.n.1.

Rationale

This change allows to more easily identify GCC versions by giving each
of the development phases distinctive versions. The change also takes
advantage of the fact that previously the GCC major number carried
little to no useful information.

My reasons for wanting to make this change:

   * Using this numbering scheme would eliminate the "+"
     from the version number that we have been using.

   * It would also make the major version number meaningful again.

   * And, it would allow us to distinguish the stable development
     version from the released stable version.  We don't currently
     do anything about that, so for example, after we released
     4.2.1, the stable branch also had that version number for
     over a year.

With this numbering scheme:

   * Any version X.0.0 means "this is an experimental development
     version".

   * Any version X.Y.1 means, "this is a pre-release version meant
     for bug fixing and testing".

   * Any version X.Y.0 with Y != 0 means "this is a released version".

Comments?

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Change version numbering scheme?

Michael Godfrey
Sounds good. I vote for doing it as soon as convenient.

On Thu, Mar 22, 2018, 08:07 John W. Eaton <[hidden email]> wrote:
I propose that we begin using a version numbering system similar to what
is now used by GCC (https://gcc.gnu.org/develop.html):


Starting with GCC 5 we will bump the major version number for each
release. The version number and DEV-PHASE will develop in the following
way and on the following timeline:

Version DEV-PHASE       When

5.0.0   (experimental)  during active development of GCC 5 (stage 1-3)
5.0.1   (prerelease)    during the stabilization period of GCC 5
6.0.0   (experimental)  during active development of GCC 6 (stage 1-3)
5.1.0           for the first release from the GCC 5 branch
5.1.1           during development on the branch post the 5.1.0 release
5.2.0           for the second release from the GCC 5 branch
5.2.1           during development on the branch post the 5.2.0 release
6.0.1   (prerelease)    during the stabilization period of GCC 6
...

To summarize, the first release of GCC 5 will be GCC 5.1.0 while
development snapshots will be GCC 5.0.0 and snapshots from the release
branch GCC 5.n.1.

Rationale

This change allows to more easily identify GCC versions by giving each
of the development phases distinctive versions. The change also takes
advantage of the fact that previously the GCC major number carried
little to no useful information.

My reasons for wanting to make this change:

   * Using this numbering scheme would eliminate the "+"
     from the version number that we have been using.

   * It would also make the major version number meaningful again.

   * And, it would allow us to distinguish the stable development
     version from the released stable version.  We don't currently
     do anything about that, so for example, after we released
     4.2.1, the stable branch also had that version number for
     over a year.

With this numbering scheme:

   * Any version X.0.0 means "this is an experimental development
     version".

   * Any version X.Y.1 means, "this is a pre-release version meant
     for bug fixing and testing".

   * Any version X.Y.0 with Y != 0 means "this is a released version".

Comments?

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Change version numbering scheme?

Mike Miller-4
In reply to this post by John W. Eaton
On Thu, Mar 22, 2018 at 11:07:04 -0400, John W. Eaton wrote:
> I propose that we begin using a version numbering system similar to what is
> now used by GCC (https://gcc.gnu.org/develop.html):

I like this idea very much. I like that it is entirely numeric and
avoids special characters and suffixes that may not sort intuitively.

I would suggest that we continue with our plan to release 4.3.0+ as
4.4.0 and keep the old version numbering intact for the upcoming
release. There has already been a lot of communication about the next
version being 4.4.0.

The default branch can be relabeled as 5.0.0.

> My reasons for wanting to make this change:
>
>   * Using this numbering scheme would eliminate the "+"
>     from the version number that we have been using.
>
>   * It would also make the major version number meaningful again.
>
>   * And, it would allow us to distinguish the stable development
>     version from the released stable version.  We don't currently
>     do anything about that, so for example, after we released
>     4.2.1, the stable branch also had that version number for
>     over a year.
Absolutely.

On Thu, Mar 22, 2018 at 09:38:15 -0700, Rik wrote:
> We should do better than what we have now.  The '+' character is fairly
> awful since it breaks things tools that are expecting only numeric version
> numbers.  If I can restate, the scheme would be MAJOR . MINOR . FLAG.  Flag
> would be 0 or 1 to indicate development or release candidate.  Or would we
> increment FLAG for every release candidate such that for stabilization,
> FLAG=1 and corresponds to rc1, FLAG=2 corresponds to rc2, etc.?

The GNOME project follows a variation on this theme that I like for
release candidates:

  * Octave 5.0.0  -  development branch
  * Octave 5.0.1  -  alpha status
  * Octave 5.0.90 -  first release candidate
  * Octave 5.0.91 -  second release candidate
  ...
  * Octave 5.1.0  -  first stable release of version 5
  * Octave 5.1.1  -  stable bug fix branch

> When would the major number change?  I know Google and its "fail fast"
> mantra have led to new major releases of their software every 6 weeks which
> I find excessive.  Would we be changing to a yearly release cycle and a
> yearly increment in the major number?  Or is it possible that there are no
> large API changes for a given year and we only update the minor release?

I think we should have been following this scheme for the past few
releases. Octave is large enough that we have essentially broken
backwards compatibility in each major release anyway and I have no
reason to expect that we won't continue to do so.

We always bump the soname for liboctave and liboctinterp with each
release

  * Octave 3.8 was liboctave.so.2
  * Octave 4.0 was liboctave.so.3
  * Octave 4.2 was liboctave.so.4
  * Octave 4.4 will be liboctave.so.5

These releases really should have been new major version numbers.

--
mike

signature.asc (849 bytes) Download Attachment