Coming Soon: Stable D Releases!

Adam Wilson flyboynw at gmail.com
Mon Jul 16 10:56:39 PDT 2012


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.

So maybe something like:

              ... 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         DMD 2.060.6 release
           v                           v
           |                           |
           >----- DMD 2.061 merge ----->

However, the precise versioning scheme is something of an open question,  
and as we gain more experience with this new development model we may  
modify this. Any feedback on this is quite welcome. All this is going to  
require some coordination with the core team.

>
> I use Github release tags so I get the correct test suite for the
> release I'm merging in.  Other than that the only other special
> information you need to know is that I use meld to sync the
> frontend and library sources together.
>
>
> Regards
> Iain


-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/


More information about the Digitalmars-d-announce mailing list