Please do not remove GCC version until a never one is officially released and available in the tree. I currently have sys-devel/gcc-13.1.0-r1, as having the latest GCC is nice for the development I'm doing. Unfortunately, it got removed from the tree before 13.1.1 or 13.2.0 got released - with current portage tree I can either accept portage complaining all the time (and hope I won't have to recompile GCC), downgrade to GCC 12, or use some unofficial pre-release version.
It's not an "unofficial pre-release" version, it's a snapshot from the stable branch which upstream encourage us to use because they only have the resources to make a release from it twice in the first year and once a year thereafter. Fedora, openSUSE, and Debian do exactly the same as us. I _can_ put it back, but there's pretty much no value in it, especially given serious bugs got fixed afterwards. If you run 'gcc --version' on Fedora, openSUSE, Debian, or Ubuntu, you'll see something very similar to what you get in Gentoo. Our approach is approved by GCC upstream. (Also, if you really did *genuinely* need it, you could always put it in a local repository).
(In reply to Roman S. from comment #0) > Please do not remove GCC version until a never one is officially released > and available in the tree. > > I currently have sys-devel/gcc-13.1.0-r1, as having the latest GCC is nice > for the development I'm doing. Unfortunately, it got removed from the tree > before 13.1.1 or 13.2.0 got released note that 13.1.1 doesn't and won't exist (that refers to the versions currently in-tree: snapshots of the 13 branch) also note that the release branches are in regression fix only mode. while it is not unheard of for these regression fixes to result in breakage on occasion, it's outweighed by the functioning fixes themselves. in essence, the quality expected of the snapshots (which are produced by upstream, btw; as an example: https://inbox.sourceware.org/gcc/20230603223643.51A323858D1E@sourceware.org/ ) is greater than that of the initial releases. > - with current portage tree I can > either accept portage complaining all the time (and hope I won't have to > recompile GCC), downgrade to GCC 12, or use some unofficial pre-release > version. I'm unsure how downgrading to 12 helps - we apply the same policy to both versions
What a mess... first they started bumping major version number like crazy, now this :/
(In reply to Roman S. from comment #3) > What a mess... first they started bumping major version number like crazy, the schedule seems reasonable. something like semver kinda fails for conglomerate software that doesn't expose a single, clean-break interface barrier (remember, gcc provides runtime libraries, and compilers, which both implement a large number of interfaces, on a bunch of platforms) i'm sure upstream would be interested in suggestions and/or critiques, please try directing those at gcc@gcc.gnu.org > now this :/ there is nothing wrong with this approach (unless you have something concrete to remark, which we can try to rectify if so). if you look at these branches you'll see that they stay quite close to releases, except with backports added in the same way we'd be doing, except (usually) by people that actually wrote the backported patches. this is a strictly better arrangement.
I promise our users are for the better with our current arrangement, or we wouldn't do it.
(In reply to Arsen Arsenović from comment #4) > i'm sure upstream would be interested in suggestions and/or critiques, please try directing those at gcc@gcc.gnu.org Somehow I don't think this is a good idea :) > there is nothing wrong with this approach (unless you have something > concrete to remark, which we can try to rectify if so). It's non-standard and misleading - usually a date in version number means this just a development snapshot, not a stable release. Also see the GCC release list, https://gcc.gnu.org/releases.html - these versions are not there. Even the official GCC documentation, https://gcc.gnu.org/snapshots.html, claims: > We also make regular snapshots available for download from our mirror sites about once a week. These snapshots are intended to give everyone access to work in progress. Any given snapshot may generate incorrect code or even fail to build. And now I see a snapshot replacing a regular release version - not fun at all, especially if you are old enough to remember the so-called "GCC 2.96". The SemVer standard was created for a reason, so that we don't have to deal with gazillion different versioning schemes, each changing from time to time to reflect trends in software marketing.
(In reply to Roman S. from comment #6) > (In reply to Arsen Arsenović from comment #4) > > > i'm sure upstream would be interested in suggestions and/or critiques, please try directing those at gcc@gcc.gnu.org > > Somehow I don't think this is a good idea :) communication is key. > > there is nothing wrong with this approach (unless you have something > > concrete to remark, which we can try to rectify if so). > > It's non-standard and misleading - usually a date in version number means > this just a development snapshot, not a stable release. Also see the GCC > release list, https://gcc.gnu.org/releases.html - these versions are not > there. Even the official GCC documentation, > https://gcc.gnu.org/snapshots.html, claims: incremental snapshot identifiers would only make it harder to cross-reference with other people, as the current snapshots are standard snapshots produced by GCC devs. calver is also rather established, fwiw, especially for things that semver can't apply to. > > We also make regular snapshots available for download from our mirror sites about once a week. These snapshots are intended to give everyone access to work in progress. Any given snapshot may generate incorrect code or even fail to build. > > And now I see a snapshot replacing a regular release version - not fun at > all, especially if you are old enough to remember the so-called "GCC 2.96". again, this is equivalent to us backporting critical patches, except upstream does it, and so, is strictly better. > The SemVer standard was created for a reason, so that we don't have to deal > with gazillion different versioning schemes, each changing from time to time > to reflect trends in software marketing. semver is not applicable here for the reasons mentioned before. this has nothing to do with marketing.
that is: the snapshots are *not* of master or trunk, they're of the stable branch for each respective release, so they're literally just rollups of backported patches. No new features, etc.
