This is the mail archive of the
mailing list for the GCC project.
Re: GCC version bikeshedding
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Andreas Schwab <schwab at linux-m68k dot org>
- Cc: Jakub Jelinek <jakub at redhat dot com>, GCC Development <gcc at gcc dot gnu dot org>, Richard Sandiford <rdsandiford at googlemail dot com>
- Date: Tue, 22 Jul 2014 15:54:38 +0200
- Subject: Re: GCC version bikeshedding
- Authentication-results: sourceware.org; auth=none
- References: <20140720165506 dot GT3003 at laptop dot redhat dot com> <7564e4f5-8030-4a23-8b0b-b1262265a349 at email dot android dot com> <87ha2ao6hj dot fsf at talisman dot default> <87zjg232tu dot fsf at igel dot home> <87d2cxon12 dot fsf at talisman dot default> <mvmfvhtltjd dot fsf at hawking dot suse dot de> <878unloma7 dot fsf at talisman dot default> <mvmbnshlstw dot fsf at hawking dot suse dot de>
On Tue, Jul 22, 2014 at 10:07 AM, Andreas Schwab <email@example.com> wrote:
> Richard Sandiford <firstname.lastname@example.org> writes:
>> Andreas Schwab <email@example.com> writes:
>>> Richard Sandiford <firstname.lastname@example.org> writes:
>>>> So if x.y.z is __GNU__.__GNU_MINOR__.__GNU_PATCHLEVEL__ then the positions
>>>> in the number stay the same but the meanings of __GNU_MINOR__ and
>>>> __GNU_PATCHLEVEL__ change.
>>> There is no change in meaning.
>> Sure there is, in terms of the release progression. The whole point of
>> the discussion is that what used to be the "patchlevel" would become
>> the "minor version".
> The patchlevel remains the patchlevel, which is the third part of the
> version number. It's no longer modified by the offcial releases, but
> that doesn't change its meaning.
Btw, we'd have the opportunity to fix one long-standing issue with our
versioning. Once we release 4.9.1 the branch becomes 4.9.2 (prerelease)
but any version checking using __GNU_PATCHLEVEL__ checking for a
fix that went into the 4.9.2 release will not work for snapshots between
the 4.9.1 and the 4.9.2 releases. Now we'd have the opportunity to
encode "prerelease" vs. "" vs. "experimental" with the patchlevel.
Say the first release from the branch will be 5.1.0 and immediately after
it we bump to 5.1.1 (_not_ 5.2.0 as we do now). For the next release
(and a single SVN revision) we bump to 5.2.0 and then immediately
to 5.2.1. And we don't have to call it "prerelease" then (which sounds
bad, worse than "postrelease" and not changing the version).
> Andreas Schwab, SUSE Labs, email@example.com
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."