On Sunday, January 06, 2013 21:15:43 Pierre Rouleau wrote: > So, given that enhancements are identified in Bugzilla, is there a > review process? Are ticket priorities and vote used? Who decides what > is the priority of an enhancement? Who assigns them?
There's pretty much never any assigning of issues in D's developement. Developers work on whatever they feel like working on. An enhancement request gets implemented, because someone decided to put the time in to implement it. If it's controversial, then it'll generally get discussed in the newsgroup, though some of that is likely to take place in the bug report itself or in a pull request if the developer implements it without discussing it first. Large language changes always get major discussions, but we also don't get a lot of those at this point. It's mostly little stuff. > Also, given that view on the development of D, what is the position on > the evolution of the language in context with backward compatibility and > stability? We're trying to reach the point where you can count on your code compiling for years without changing it. We're getting there, but it doens't always happen. Even fixing bugs breaks code when code relies on buggy behavior. There's also still some API changes in Phobos which breaks stuff, but we've been cutting back on those and trying to avoid them, so they happen much less now then they used to. The recent change to make deprecated warn instead of giving an error should help with that. > How can an organization of D users that are not also D > developers can plan a project and use D for it? > > Do you consider D stable enough for outside users/organizations to start > using it in their own projects? It's stable enough as long as you're continually working on your code. If you let it sit for a long period of time, you're likely to need the same compiler and library version that you used when you last worked on it. Breakages are _far_ fewer than they used to be, but they still happen. I'd expect that anyone using D seriously for professional development would stick to one version of the compiler for a while and then upgrade it when they have time to update their code (which they may not need to do, but it's still not quite to the point that there isn't at least a decent chance that a few lines of code will have to be changed). API breakage does occur sometimes, but we're making an effort to keep that to a minumum, and we'd like to get rid of it completely. But regardless, I believe that most breakages at this point are due to bug fixes, so when we'll reach the point that you can really expect your code to continue to compile for years on newer compilers without trouble, I don't know. That may depend primarily on the bugs that we have left and how well regressions get caught. The work that's currently being done on formalizing and ironing out the release process should help with that though. - Jonathan M Davis
