On Mon, 16 Jul 2012 11:12:38 -0700, Iain Buclaw <ibuc...@ubuntu.com> wrote:
On 16 July 2012 18:56, Adam Wilson <flybo...@gmail.com> wrote:
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.
And how does DMD backend support for COFF affect GDC? :-)
Very little I imagine. But we are working against DMD. Since you only want
the front-end fixes, I imagine that (at least in terms of the backend) you
won't care much when we merge that feature. My point was more general to
versioning, in that we might update the stable branches to the new release
day one. The new fixes will still appear though. Obviously this would have
more impact for you with any new front-end features.
--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
