[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
signature.asc
Description: PGP signature