Re: GCC multi-version development layout

> Sent: Monday, April 20, 2026 at 4:35 PM
> From: "Jonathan Wakely via Gcc-help" <[email protected]>
> To: "Heime" <[email protected]>
> Cc: "Xi Ruoyao" <[email protected]>, "gcc-help" <[email protected]>
> Subject: Re: GCC multi-version development layout
>
> On Mon, 20 Apr 2026 at 15:32, Jonathan Wakely <[email protected]> wrote:
> >
> > On Mon, 20 Apr 2026 at 12:39, Heime <[email protected]> wrote:
> > >
> > > On Monday, April 20th, 2026 at 10:28 AM, Jonathan Wakely via Gcc-help <[email protected]> wrote:
> > >
> > > > 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 confusion is the switch from GCC 4.9.4 release to GCC 5.1 release.
> > > Do releases post GCC 4.9.4 in actual fact include an additional .0?
> > > For instance, GCC 5.1 is actually GCC 5.1.0?
> > >
> > > > > 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.
> > >
> > > The implication vs reality is what creates the confusion.  If 5.1.0
> > > is the release, what would be 5.1.1, 5.1.2, ... - do they exist in
> > > the git development phase?
> >
> > There is no 5.1.2, it never exists.
> >
> > 5.1.1 is a snapshot from the gcc-5 branch between the 5.1.0 and 5.2.0
> > releases. It's not a release.
> >
> >
> > >
> > > Does a change in the DEV-PHASE, result in a numbering change in the
> > > git repository?
> >
> > No.
> 
> The version number is set from gcc/BASE-VER.

I suggest the inclusion of information upon snapshots, 
explaining versions such as 15.2.1 in file gcc/BASE-VER.

It seems to me that a discussion about gcc/BASE-VER is
germane to the discussion about gcc development and
resulting snapshots.
 
> >
> > >
> > > > 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.
> > >
> > > The confusion originates here: honour the actual release format in
> > > the timeline documentation.  Perhaps the full timeline is not needed,
> > > and you only need an actual timeline with correct release numbering
> > > for just 3  major branches (14, 15, 16) would be enough.
> >
> > No, this is totally wrong. The point of the release timeline is to see
> > when various important events happened in the history of GCC. I want
> > to know the date on which GCC 9.3.0 was released, so I can look at the
> > timeline. If it only shows the active branches, that timeline would be
> > completely useless for most of the times I consult it.
> >
> > Again, the timeline is not there to define the meaning of the version
> > numbers, it's a timeline! It shows when things happened!
> >
> > If you're trying to use the timeline to understand the version
> > numbering, you're using it wrong.
> >
> > >
> > > The implication that 5.1.0 can be described as 5.1 can be explained
> > > later.  Or, if 5.1 is better, the explanations have to be improved.
> > >
> > > Clarity must prevail over convenience for true understanding.
> > > Keep in mind that the page is trying to explain GCC Development
> > > to people who do not know.
> > >
> > > > If you don't understand the numbering scheme, read the definition of
> > > > the numbering scheme again, not the timeline.
> > >
> > > What does this mean: snapshots from the release branch GCC 5.n.1.
> >
> > It means exactly what it says. We could add the words "will be" so
> > that it says "snapshots from the release branch will be GCC 5.n.1" but
> > the meaning is identical in English.
> >
> > So a snapshot from the gcc-5 branch will be 5.1.1 or 5.2.1 or 5.3.1 or 5.4.1.
> >
> > >
> > > You may think everything is fine, but to others from the outside,
> > > the description and examples, and switching to implications from your
> > > minds in not fine at all.
> > >
> > > Although it may be clear to some, the information is not really complete.
> >
> > I disagree, the information is all there. Maybe it could be clearer,
> > but it's all there.
> >
> > >
> > > > >> This produces confusion and lacks usefulness to fresh gcc developers
> > > > >> trying to make sense of the actual current scheme.
>