octave-maintainers
[Top][All Lists]
Advanced

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

Re: Change version numbering scheme?


From: Mike Miller
Subject: Re: Change version numbering scheme?
Date: Thu, 22 Mar 2018 10:50:00 -0700
User-agent: Mutt/1.9.4 (2018-02-28)

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

Attachment: signature.asc
Description: PGP signature


reply via email to

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