Re: GCC multi-version development layout

On Mon, 20 Apr 2026 at 09:25, Jonathan Wakely <[email protected]> wrote:
>
>
>
> On Mon, 20 Apr 2026, 00:21 Heime, <[email protected]> wrote:
>>
>>
>>
>>
>>
>> Sent with Proton Mail secure email.
>>
>> On Monday, April 20th, 2026 at 12:34 AM, Jonathan Wakely via Gcc-help <[email protected]> wrote:
>>
>> > On Sun, 19 Apr 2026, 23:30 Heime, <[email protected]> wrote:
>> >
>> > > On Sunday, April 19th, 2026 at 7:50 PM, Jonathan Wakely via Gcc-help <
>> > > [email protected]> wrote:
>> > >
>> > > > On Sun, 19 Apr 2026, 17:57 Xi Ruoyao via Gcc-help, <[email protected]
>> > > >
>> > > > wrote:
>> > > >
>> > > > > On Sun, 2026-04-19 at 16:33 +0000, Heime via Gcc-help wrote:
>> > > > > > ----------------------------------------------------------------
>> > > > > >
>> > > > > > When building GCC from a cloned Git source tree using separate
>> > > > > > directories (as recommended), the directory structure follows
>> > > > > > a clean separation of source, build artifacts, and final
>> > > > > > installation.
>> > > > > >
>> > > > > > With different version of gcc, how would be the typical layout
>> > > > > > for specific branches to make patch changes to different gcc
>> > > > > > versions with multiple builds and install?
>> > > > >
>> > > >
>> > > > The layout doesn't matter at all. Anything will work.
>> > > >
>> > > > I have a directory ~/src/gcc/gcc for the git repo, where I work on trunk
>> > > > and then directories ~/src/gcc/gcc-15 and ~/src/gcc/gcc-14 etc for each
>> > > > release branch, using git worktree.
>> > > >
>> > > > I install each version to ~/gcc/X where X is 16, 15, 14 etc.
>> > > >
>> > > > But it really doesn't matter, anything works.
>> > > >
>> > > >
>> > > > > See https://git-scm.com/docs/git-worktree.
>> > > > >
>> > > >
>> > > > This is definitely the best way to manage the repo, so that every release
>> > > > branch is just a worktree using the same repository metadata and config
>> > > > settings.
>> > >
>> > > Have been scrutinising the development timeline page
>> > >
>> > > https://gcc.gnu.org/develop.html#timeline
>> > >
>> > > The new GCC versioning scheme announced for GCC 5.1 is
>> > > not reliably described.  For instance, a major version
>> > > number increases GCC X to GCC X+1 (no more GCC X.Y to
>> > > GCC X.Y+1).
>> > >
>> > > The stage number does not seem to be added as a version
>> > > (there is no GCC X.0.1 (for stage 1), GCC X.0.3 (for stage 3)),
>> > > and so on.
>> >
>> >
>> > That's correct.
>> >
>> >
>> > >
>> > > It would help if the page got updated with improved descriptions.
>> > >
>> >
>> >
>> > I don't see a problem with it, what improvement are you suggesting?
>>
>> The "Version DEV-PHASE When" table under "Version Numbering Scheme
>> for GCC 5 and Up" shows GCC-5.Y.Z and GCC-6.Y.Z, which do not reflect
>> the actual "Release Timeline" described as GCC-5.Y and GCC-6.Y.
>
>
> I don't agree and I don't see what's confusing about this.
>
> A release has Y != 0 and Z == 0
>
> The 5.2 release means 5.2.0 (which is already clearly stated in the table). Is that the source of your confusion? You don't understand what "5.2" means in the timeline? We could add ".0" to every release in the timeline but IMHO that would make it more cluttered for very little value.
>
> The description of the version numbering is 100% accurate, and complete. The release timeline is also 100% accurate but simply omits the redundant ".0" on releases since 5.1.0, because it's redundant. All releases since 5.1.0 have ".0" at the end, so there's no need to say it on every release. It's implied, because all releases end with ".0", as defined above the timeline.

To put it another way: the release timeline is not supposed to define
the numbering scheme. That's defined above. The release timeline is
just informative, documenting the timeline, not documenting the
format.

If you don't understand the numbering scheme, read the definition of
the numbering scheme again, not the timeline.




>
>
>>
>> This produces confusion and lacks usefulness to fresh gcc developers
>> trying to make sense of the actual current scheme.
>>
>>
>>