This is the mail archive of the
mailing list for the GCC project.
Re: GCC version bikeshedding
- From: Joern Rennecke <joern dot rennecke at embecosm dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Eric Botcazou <ebotcazou at libertysurf dot fr>, Ian Lance Taylor <iant at google dot com>, GCC <gcc at gcc dot gnu dot org>, Jason Merrill <jason at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>
- Date: Tue, 29 Jul 2014 18:26:21 +0100
- Subject: Re: GCC version bikeshedding
- Authentication-results: sourceware.org; auth=none
- References: <20140720165506 dot GT3003 at laptop dot redhat dot com> <53CF8E48 dot 8090003 at redhat dot com> <CAKOQZ8yvTaos4Qo=cBEF070_rZkF9V-2L-76R6i7KLisBMEn-g at mail dot gmail dot com> <201407291845 dot 14107 dot ebotcazou at libertysurf dot fr> <2745817d-ab90-42eb-9e79-9805b4f11573 at email dot android dot com>
On 29 July 2014 18:14, Richard Biener <email@example.com> wrote:
> On July 29, 2014 6:45:13 PM CEST, Eric Botcazou <firstname.lastname@example.org> wrote:
>>> I think that if anybody has strong objections, now is the time to
>>> them. Otherwise I think we should go with this plan.
>>IMHO the cure is worse than the disease.
>>> Given that there is no clear reason to ever change the major version
>>> number, making that change will not convey any useful information to
>>> our users. So let's just drop the major version number. Once we've
>>> made that decision, then the next release (in 2015) naturally becomes
>>> 5.0, the release after that (in 2016) becomes 6.0, etc.
>>I don't really understand the "naturally": if you drop the major
>>number, the next release should be 10.0, not 5.0.
> 10.0 would be even better from a marketing perspective.
So if we want version number inflation with plausible deniability, how
about we first increment the miner version number - so we get 4.10.0,
and then we concatenate major and minor version number, yielding