Re: GCC multi-version development layout

On Monday, April 20th, 2026 at 6:26 PM, Jonathan Wakely <[email protected]> wrote:

> On Mon, 20 Apr 2026 at 16:57, Heime <[email protected]> wrote:
> >
> > On Monday, April 20th, 2026 at 5:35 PM, Jonathan Wakely <[email protected]> wrote:
> >
> > > On Mon, 20 Apr 2026 at 16:23, Heime <[email protected]> wrote:
> > > >
> > > >
> > > > On Monday, April 20th, 2026 at 4:33 PM, 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.
> > > > >
> > > > > >
> > > > > > > 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.
> > > >
> > > > You mean from the release branch 5.n.  It is the 5.n.1 that is confusing
> > > > It is more understandable if it states that the GCC 5.N.M is snapshot M
> > > > from the release branch GCC 5.N.
> > >
> > > No. There is no 5.n branch.
> > >
> > > The branch is releases/gcc-5 or releases/gcc-6 etc.
> > > See https://gcc.gnu.org/cgit/gcc/refs/
> > >
> > > Like I said, this is all in the table. Read it more carefully. It says
> > > that GCC 5.1.0 is the first release from the GCC 5 branch (which is
> > > 'releases/gcc-5' in git). It doesn't say the GCC 5.1 branch, because
> > > there's no such branch.
> > >
> > > GCC 5.1.1 is a snapshot from the gcc-5 branch. GCC 5.2.0 is the second
> > > release from that branch. GCC 5.2.1 is a snapshot from that branch.
> > > GCC 5.3.0 is the third release from that branch, and so on.
> > >
> > >
> > > >
> > > >
> > > > > 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.
> > > >
> > > > Things need to be clearer.  The page tries to discuss both the
> > > > GCC Development Plan and the Timeline.  To be clearer, separate
> > > > the development plan from the timeline to be in different pages.
> > >
> > > That's not necessary, they're separate but related things. They both
> > > belong on the develop.html page. It's not the "version numbering"
> > > page, so there's no reason it should *only* talk about version
> > > numbering.
> > >
> > > > For understanding, one should be able to see any imaginary GCC
> > > > version and be able to explain what it is.  If one needs an
> > > > explanation of what a version means, then there is something
> > > > wrong with the versioning scheme.
> > >
> > > I see no reason why our docs should explain what GCC 5.banana.fitter means.
> >
> > Any "Version Numbering Scheme" must explain GCC 5.banana.fitter.  Because any
> > name must fully derive its meaning from the scheme itself.  If it doesn't, the
> > scheme is useless - you're better off with a plain timeline table naming releases
> > arbitrarily.
> >
> > Otherwise GCC 5.banana.fitter constitutes a broken promise: Readers see
> > 5.banana.fitter expecting the scheme to decode it.  If it can't, discard it.
> 
> Where do readers see that? It's completely made up, it's not used by
> any GCC release.
> 
> 
> >
> > Forcing timeline lookup defeats the purpose of the Version Numbering Scheme.
> 
> I have no idea what this means. I've said repeatedly you should stop
> trying to use the timeline to understand the numbering scheme. Are you
> trolling now?

The timeline uses the numbering scheme, but I have to accept that the numbering
scheme in the timeline cannot be used to understand the numbering scheme.

I'm not trolling, I'm detonating the contradiction right in your face!
When a man stands knee-deep in the steaming wreckage of a "versioning 
scheme" that can't decode its own structure, it isn't trolling.

> > Version strings exist to be intrinsically meaningful without external context.
> 
> And completely imaginary version strings like 5.2.2 and
> 5.banana.fritter do not exist, at all. So they don't need to be
> explained. Your confusion about what 5.2.2 means was because you just
> made something up in your head and decided it was a problem because
> you couldn't understand what that version meant.
> 
> >
> > This is basic information design.  GCC 5.banana.fitter must immediately convey
> > something (GCC 5 series, experimental snapshot, iteration F.).
> 
> I'm done with this stupid thread. Good luck finding a release of GCC
> 5.banana.fritter in the real world.

Here comes the classic kill-shot: "I'm done with this stupid thread. 
Good luck finding GCC 5.banana.fritter in the real world." 

It's the equivalent of flipping the Monopoly board and storming off 
to the liquor cabinet - pure, unfiltered contempt for everyone who 
dares breathe oxygen in the discussion concerning your genius.

Fake superiority that calls us all drooling idiots, and peels out 
in a haze of self-righteousness.
 
> >
> > > >
> > > > To list the timeline of what is released is not bad, if not
> > > > cluttered by a lot of other unrelated information.  A release
> > > > timeline page would provide the information.
> > > >
> > > > How would one know whether 5.0.1 is in experimental stage 4 or in
> > > > prerelease?
> > >
> > > They're the same thing.

The table in "Version Numbering Scheme for GCC 5 and Up" does not imply they
are the same thing.