On 11 November 2013 16:49, Dicebot <public@dicebot.lv> wrote:

> On Monday, 11 November 2013 at 16:46:50 UTC, Iain Buclaw wrote:
>
>> Nobody makes that complaint about gccgo.  So what you are describing is an attitude unique to this community.
>>
>
> How do they handle language updates in gccgo?
>

There is current no 'release' per say for Go.  So the version of Go would be whatever was the current stable as of the GCC release (or closing of stage1 development).

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Monday, 11 November 2013 at 17:05:15 UTC, Iain Buclaw wrote:
> There is current no 'release' per say for Go.  So the version of Go would
> be whatever was the current stable as of the GCC release (or closing of
> stage1 development).

Well, you do realize it is completely unsuitable for D and will never work this way, don't you? :) And while I generally like to rant about lack of stable development process, GCC inverted approach seems much worse for anything that is not set in stone language covered by formalistic standard.

On 11 November 2013 17:42, Dicebot <public@dicebot.lv> wrote:
>
> On Monday, 11 November 2013 at 17:05:15 UTC, Iain Buclaw wrote:
>>
>> There is current no 'release' per say for Go.  So the version of Go would be whatever was the current stable as of the GCC release (or closing of stage1 development).
>
>
> Well, you do realize it is completely unsuitable for D and will never
work this way, don't you? :) And while I generally like to rant about lack of stable development process, GCC inverted approach seems much worse for anything that is not set in stone language covered by formalistic standard.

It can work this way.  Perhaps with the realisation of a more stable releases (eg: exercising that certain point releases get maintained for a year).

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
On Monday, 11 November 2013 at 17:05:15 UTC, Iain Buclaw wrote:

> There is current no 'release' per say for Go.  So the version of Go would be whatever was the current stable as of the GCC release (or closing of stage1 development).
>

Well, you do realize it is completely unsuitable for D and will never work this way, don't you? :) And while I generally like to rant about lack of stable development process, GCC inverted approach seems much worse for anything that is not set in stone language covered by formalistic standard.

GCC releases are as often as D releases now when I compare the 4.8.x series with the last D versions: 2 to 5 months.

-- 
Marco

On Tuesday, 12 November 2013 at 06:37:03 UTC, Marco Leise wrote:
> GCC releases are as often as D releases now when I compare the
> 4.8.x series with the last D versions: 2 to 5 months.

Yeah and Ubuntu still has 4.6 in main repos ;) It isn't as much GCC upstream issue as problem with being forced to sync with GCC suite updates in distributions (and thus being tied to stability requirements for C compiler updates in that distributions).

On Monday, 11 November 2013 at 21:31:50 UTC, Iain Buclaw wrote:
> It can work this way.  Perhaps with the realisation of a more stable
> releases (eg: exercising that certain point releases get maintained for a
> year).

I would have fully supported it but if it has not happened so far despite all the breaking change debates I can't see it happening in future just because of GCC.

Am Sat, 9 Nov 2013 01:38:10 +0100
schrieb Marco Leise <Marco.Leise@gmx.de>:

I abandoned my "gdc" ebuild and instead just copied
the original gcc ebuild and augmented it with a specific
checkout of gdc from Github. This means that you can freely
slot it with your existing gcc installation(s) or replace it
entirely. This lets us work with it as if D was already
officially included in gcc.
Currently there is gcc 4.8.1 with front-end version 2.063.2.
gcc 4.8.2 will have the 2.064.2 integration.
Libraries compiled with gdc will be placed in the existing
version specific gcc directory
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/
to avoid collisions with the same .so files compiled with
other D compilers.

-- 
Marco