> 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
> * 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".
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.?
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?