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 <[email protected]>:
On 16 July 2012 14:00, Marco Leise <[email protected]> wrote:
> Am Mon, 16 Jul 2012 00:51:16 -0700
> schrieb "Adam Wilson" <[email protected]>:
>
> 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 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
