Re: GCC multi-version development layout

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.

 
> 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.

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.

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?

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