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) ?
