GCC 10.2 Released

[Iain Sandoe]

  FX,

Martin Liška <mliska@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