FX,
Martin Liška <mli...@suse.cz> wrote:
On 12/23/20 11:49 AM, FX via Gcc wrote:
Hi all,
The gcc 10.2 release was 5 months ago today. A lot has happened in the
gcc-10 branch since, in particular on aarch64. Could a new release be
issued? It would make efforts at maintaining patches on top of the
gcc-10 branch easier, in particular in view of the release of
aarch64-apple-darwin machines.
Hello.
I understand your situation, but based on our release schedule, please
expect 10.3 to
be released at the beginning of March 2021, similarly to what we did for
9.3 and 8.3:
GCC 9.3 release (2020-03-12)
GCC 8.3 release (2019-02-22)
as seen here:
https://gcc.gnu.org/develop.html
Note that making a release consumes some cycles mainly for release
managers.
Thanks for understanding,
[FAOD I am not disagreeing with what you say, I personally have quite a
backlog of backports for 10.x, not to mention fixes to make to coroutines
that should also be applied there… ]
Nevertheless:
We have an unusual situation in that we have:
- a major OS release that has incompatible numbering with the preceding ones.
- a new architecture to support (which will not be ‘official’ in 10.x even if,
by some miracle, it’s ready for 11).
So I think it might be possible to help the Darwin ‘downstreams’ by making
the equivalent of a “vendor” branches for Darwin - in this case [for open
branches] based on some arbitrary point in time (e.g. 1.1.2021) rather than
on a GCC dot release.
For the closed branches that we want to be able to build on Darwin20, the
base can be the last dot release.
Those branches could live in users/darwin or vendors/darwin .. (we kinda
started discussing that on irc one day) - I guess I don’t have a big axe to
grind on which [but it’s probably better in one of those, than under my
user or on github].
It would be clear that this is Darwin-specific [branch name amended, for
example] (i.e. that test coverage was concentrated on the platform).
This would not be something I’d want to make a habit of - as Martin says
(even for regular maintainers) release cycles chew a lot of time and
resources in wider testing.
Open to other suggestions, of course,
Iain
