Account on ARM/Debian

[Joseph Rushton Wakeling]

On 10/17/2012 06:37 PM, David Nadlinger wrote:
> Well, that depends on your definition of stable. LDC Git master is supposed
> always pass the CI tests, i.e. the DMD, druntime and Phobos test suites.

Which would explain my (limited, as I haven't been doing any development 
recently) experience of it seeming very stable and effective when built (and 
rebuilt) from git sources. :-)

Have any optimization improvements landed recently?  It really seems like since 
my last email on the subject, the speed of executables has improved to be about 
the same as GDC.

> A possible extension of that would be to have a separate »stable« Git branch
> which is automatically advanced along with master by the CI system whenever a
> given revision passes all the tests. If somebody wants to set up a system like
> this, I'd be happy to officially adopt it.

That's not what I was really thinking about -- I trust you and the other LDC 
devs to make sure things pass all the automated tests before merging into master.

> But in my experience, anything more than that, i.e. declaring revisions stable
> based on criteria which can't be evaluated by an automatic test suite, is not
> worth it, at least for smallish projects like LDC. Judging whether a given state
> is stable by hand is notoriously hard to get right, and the reason we have beta
> phases before releases, etc.

What I had in mind was that you might define a "stable" branch which is updated 
according to certain new-feature milestones, and which in the interim between 
those milestones only receives bugfixes, not new features.

I guess the benefits of doing this depend on the extent to which you have a 
well-defined roadmap which would let you define a "milestone", though it might 
be possible to do it on the basis of the frontend/druntime/phobos version.

It probably seems not-worth-doing unless you are making official releases 
anyway, but from my point of view as a "consumer" of LDC it feels like a nice 
option to be able to have a branch that is updated more slowly -- i.e. with 
material that isn't just the latest patches, but that has been around for a 
while so that the devs have had time to spot any holes.