On Mon, 16 Jul 2012 10:26:31 -0700, Iain Buclaw <ibuc...@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 <ibuc...@ubuntu.com>:
On 16 July 2012 14:00, Marco Leise <marco.le...@gmx.de> wrote:
> Am Mon, 16 Jul 2012 00:51:16 -0700
> schrieb "Adam Wilson" <flybo...@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/