Release process and backwards compatibility

[Rikki Cattermole]

On Friday, 8 March 2013 at 21:07:23 UTC, Jakob Ovrum wrote:
> 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.

Personally I think we need to consider D3 as breaking. We can 
leave out any major changes till then or at least that would be 
nice. That way we can use D2 for LTS once we begin on D3.
How ever this will bring back e.g. the old python 2.x vs 3.x 
divide which would be a shame. But at the same time it'll mean we 
can do some big stuff that would just not be acceptable in 
breaking old projects.