Coming Soon: Stable D Releases!

[Iain Buclaw]

On 16 July 2012 18:56, Adam Wilson <flyboynw at gmail.com> wrote:
> On Mon, 16 Jul 2012 10:26:31 -0700, Iain Buclaw <ibuclaw at ubuntu.com> wrote:
>
>> On Monday, 16 July 2012 at 16:39:45 UTC, Marco Leise wrote:
>>>
>>> Am Mon, 16 Jul 2012 17:21:39 +0100
>>> schrieb Iain Buclaw <ibuclaw at ubuntu.com>:
>>>
>>>> On 16 July 2012 14:00, Marco Leise <Marco.Leise at gmx.de> wrote:
>>>> > Am Mon, 16 Jul 2012 00:51:16 -0700
>>>> > schrieb "Adam Wilson" <flyboynw at gmail.com>:
>>>> >
>>>> > As it shows, the beta phase doesn't always catch all > regressions in
>>>> > people's code, so I encourage you to do this > project and eventually it
>>>> > will be used by GDC and other > major from-source projects. By the way:
>>>> > Should this also > later become the base for the official zip file download?
>>>> > > IIRC Walter wanted to keep track of the DMD downloads from > the main web
>>>> > site (no redistribution) and hotfixed versions > of D could become
>>>> > increasingly popular.
>>>> >
>>>> > --
>>>> > Marco
>>>> >
>>>>  And what benefits would GDC get from opting to use this rather than
>>>> the normal releases?
>>>
>>>
>>> What he said, [regression] fixes that didn't make it into the initial
>>> release. I don't know about GDC's 'patch level', but for 2.059 I applied
>>> patches for the following issues after release, to have it feel as solid as
>>> good old 2.058:
>>> - issue-7907
>>> - issue-7911
>>> - issue-7922
>>> - outOfMemoryError-undeprecation
>>> - std-path-sep-deprecation
>>>
>>> In case crypto algorithms become part of Phobos, some patches may improve
>>> security as well. Didn't you say you work only with the GitHub release tags
>>> for stability?
>>
>>
>> So if I were to represent a theoretical merge sequence in ascii:
>>
>>             ... former releases ...
>>     DMD Development             GDC Development
>>          >---- DMD 2.060 release ---->
>>          |                           |
>>      DMD Development         DMD 2.060.1 release
>>          v                           v
>>          |                           |
>>          |                   DMD 2.060.2 release
>>          |                           v
>>          |                           |
>>          |                   DMD 2.060.3 release
>>          |                           v
>>          |                           |
>>      DMD 2.061 beta          DMD 2.060.4 release
>>          v                           v
>>          |                           |
>>      DMD 2.061 RC            DMD 2.060.5 release
>>          v                           v
>>          |                           |
>>          >-- DMD 2.061 release ------>
>>
>>
>> Would this be a correct way of utilising this new process?
>>
>
> I'd say mostly correct. The last step is the one where we might differ
> though, as we may choose to wait on regression and other bug-fixes to any
> new features in that release. But we might not wait if the build consists of
> no new features, just breaking changes to existing ones. It will be more of
> a conversation with the community about how stable they feel the changes in
> the latest release are. For example, of the new COFF support is still highly
> unstable (lots of fix commits), we might wait until that settles down before
> merging in the entirety of the development repos.
>

And how does DMD backend support for COFF affect GDC? :-)



-- 
Iain Buclaw

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