dmd development model.

[Moritz Warning]

On Mon, 12 Oct 2009 14:48:17 -0400, Eldar Insafutdinov wrote:

> This has been raised numerous times by many people before, but still I'm
> going to write it. The last three releases are broken for both QtD and
> tango. Why is it happening? I see the reason in the dmd development
> model. Say dmd 2.031 works for a project (which can be a large one). The
> consequent release 2.032 does not. If you make a diff between the two
> versions it's considerably large. How are we supposed to locate the
> regression?
> 
> If dmd delepers contributed every change to the VCS separately, it would
> be much easier to track down the change that caused the issue. From my
> side I could test the version of dmd from trunk every 2 days and file
> bugs as they appear. That's how most of the open source projects work,
> and this model works fine. Few days before the release there can be an
> appropriate notice, so that people could test their code. That would
> make dmd releases less buggy. I know that Walter sends the compiler to
> tango devs prior to release, but that's not a robust solution to the
> problem, developers may not have time at the moment for example. However
> with the truly open model not only core developers of projects, but
> anyone can test the compiler.
> 
> What we have now is annoying. We have a series of non-working releases.
> LDC for example still hasn't updated it's front-end since dmd 1.045.
> Putting dmd to svn was a great move, but without adopting the advantages
> of VCS it's rather useless.
> 
> Thank you,
> Eldar.

Same opinion here.
There are quite some nice fixes in the last releases,
but it's useless if other regressions make it unusable.

I (sort of) understand why Walter can't look at other projects code
and can't even test it for legal reasons.


This problem would be solved by multiple commits over time (between 
releases). Users can test their projects against dmd trunk (Tango, QTD to 
name only a few).
It would be easier to locate and fix problems _before_ releases.
No beta/Pre- releases are needed.

A VCS is not for final code, it's for dirty work.
trunk don't have to contain shiny code with a history of complete commits.
It's allowed to be messy.