D versionning

[deadalnix]

On 12/07/2012 21:25, Jonathan M Davis wrote:
> There would definitely be value in the long run in having a similar versioning
> scheme, but I think that we're still ironing enough out that there's not much
> point yet. We don't want people to continue to code against verison 2.X.Y
> instead of moving their code to 2.X+1.Y. We want people to update their code
> to the newest version. We provide appropriate deprecation paths to ease
> transition, but we don't want to be supporting older versions of stuff. If you
> really want to stick with what dmd 2.059 provides because 2.060 deprecates
> something that you want, then just stick with 2.059. You don't need a new
> versioning scheme to do that.
>

You may want to benefit from bug fixes even if you don't want to migrate 
to the new functionality yet. Sticking with 2.059 is somehow problematic.

Plus, when a breaking change need to be introduced, we currently only 
have the choice to talk about it on a theoretical perspective. Being 
able to play with it without it being integrated in the last « release » 
version is something that the language definition would benefit greatly 
from.

It is clear that for now, we would be unable to support version for a 
very extended period of time (we aren't as big as PHP). I still think we 
can benefit from that.

According to you, what are the drawbacks of switching to that (as, if I 
understand you correctly, you think this will be useful in the future, 
but not now) ?