Re: GCC multi-version development layout

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.



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