> 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
