Release process and backwards compatibility

[Jakob Ovrum]

On Friday, 8 March 2013 at 20:07:50 UTC, Dicebot wrote:
> Opinions/proposals?

I completely agree that the needs of users who want stability 
over everything are not being met. There's no way to choose to 
get just the updates that don't break code (such as non-breaking 
bug fixes), and I think you're right in that there should be a 
way to do that.

However, I just want to make clear that there's another (probably 
rather big) camp out there: the camp that thinks the current D 
platform needs a lot of improvement and are more than willing to 
accept breaking improvements.

I want more language features to be implemented and cleaned up. I 
want Phobos to be changed, cleaned up, trimmed as well as 
expanded. All this regardless of the cost of breaking code. I 
don't mind fixing broken code if the replacement code is simply 
better.

Thankfully, both the language and standard library are currently 
being improved in such ways, but not without a fair amount of 
inertia from parts of the community (particularly from Walter) 
who want stability at all costs.

For example, I don't think the current std.process is adequate at 
all and it would feel like a defeat if we have to name the new 
one std.process2 and have it live alongside the old trash (unless 
it's temporary). What do you think new users will think when they 
see or hear about the story around this? Many other standard 
modules are in the same position or are going to be in the same 
position at some point in the foreseeable future.

I just hope we can find a way to satisfy both camps, both 
ensuring the viability of the language at present by providing a 
stable interface, as well as securing the future of the language 
by iteratively improving upon it without compromising at every 
turn. Having LTS releases might be a good way to do that.