Breaking D2 language/spec changes with D1 being discontinued in a month

[Robert]

> Is there absolutely no concern for D users's code? It certainly 
> seems like it. Maybe it would have made sense a decade ago when D 
> was just starting... but D has been around for over 11 years now. 
> To have screwed up so badly that after 11 years you still don't 
> have a stable platform to write code for (well, you do with D1, 
> but in a month there will not be that excuse) is mind boggling.

I tend to disagree a bit. First D is a very, very powerful language
written by just a few people, with no commercial background, so I think
it is quite reasonable that it takes more time to stabilize than much
simpler languages, let's say python.

I also in general think, that fixing things is a good idea, even if
breaking code, but it is really annoying if your code breaks, especially
if you can not easily find the reason.

For this reason and others (more testing) I would also very much
appreciate (I already suggested this before) to have a stable branch,
that really only receives bug fixes and a new major version release
every half a year or so (given D's speed of development). It should not
be too frequent, because it will be a lot of work:

1. Document precisely any breaking changes for the new version + a
recommend way of updating (which was tested).
2. Provide tools that fix your code automatically. Wherever reasonable &
possible.

Because I think, the least you can do is to have a thorough discussion
somewhere of what breaks and how to fix it. I would be very much less
pissed by breaking changes, if I could at least look them up quickly and
get a solution for it.

For point 2, we would start with some easy tools like search and replace
(for name changes and such) and improve them over time to parse
context, ... (e.g. like http://coccinelle.lip6.fr/sp.php  )
-> The easier and automated the upgrade path, the better.

Old version could be supported until the major version after the next
one comes out. Encourage people to upgrade early and make it as easy as
possible for them.

Are breaking changes of any kind documented somewhere at the moment?

The release model I have in mind:
1. Every few months a new minor release for both the unstable and the
stable version. (To get early and good testing for the unstable version
& to find out any unexpected breakings)
2. Every six/eight/twelve months: The current unstable will become the
new stable with all breakings perfectly documented & uprade scripts
written.

If it is too much work to support two stable versions, we could drop
updates as soon as a new version comes out.

Breaking changes should still be avoided of course, but if needed they
should be possible.

Best regards,

Robert