D 1.076 and 2.061 release

[Jonathan M Davis]

On Monday, January 07, 2013 08:09:01 Pierre Rouleau wrote:
> The worst part I see is that bug fixes and new feature introductions are
> lumped together inside releases. Combined with the fact that the
> development is not predictable means that if you develop products with D
> you have to keep updating it.  If you get stuck with a bug and wait for
> the release that fixes it, when that release comes out it could very
> well bring new language features that break the code that you have
> already written.
> 
> It would be nice to have bug fixes separated from new feature
> introductions by having major and minor releases and branches for these
> releases.  Contributors of a release could backport bug fix in the
> release they use if that was required by their project using the now old
> compiler version.
> 
> Of course I realize that this means more overall work, more people,
> someone or a set of people in charge of release management, etc...

The reality of the matter is that most code breakage comes from bug fixes. New 
features rarely break much of anything, especially if you're not using them. 
Having API changes mixed in with bug fixes _can_ pose a problem, but I think 
that if you really looked into it, you'd find that stuff like UFCS and UDAs and 
whatnot have resulted in very little (if any) broken code. They may not have 
worked as well as they should have and have plenty of bugs in their 
implementation, but code which isn't using them (as code wouldn't be prior to 
their release) didn't get broken by its introduction. So, while it may be 
valuable to move to a major/minor release situation, I think that the reality 
of the matter is that it will have little effect on stability simply because 
it's bug fixes which break things - either because they fix previously buggy 
behavior (breaking any code which relied on that behavior) or because 
regressions are introduced, and while we try hard to catch those, we don't 
always manage it. And the only thing that I can think of which would do a 
better job of catching those would be a bettere beta program where the beta is 
somehow better vetted so that regressions just don't manage to get through 
(though how we'd get more people to try the beta, I don't know). Major and 
minor releases will have little effect on stability from the standpoint of the 
compiler. They could have an effect from the standpoint of API changes, but 
since we're trying to stop making breaking API changes entirely (or at least 
make them very rare), a major/minor release model probably won't help much 
there either.

- Jonathan M Davis