This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC version bikeshedding

On Tue, Jul 22, 2014 at 10:07 AM, Andreas Schwab <> wrote:
> Richard Sandiford <> writes:
>> Andreas Schwab <> writes:
>>> Richard Sandiford <> 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.
> --
> Andreas Schwab, SUSE Labs,
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]