D versionning

Jonathan M Davis jmdavisProg at gmx.com
Thu Jul 12 12:25:57 PDT 2012


On Thursday, July 12, 2012 18:49:16 deadalnix wrote:
> One thing PHP has been good at is evolving, and introducing change in
> the language (some can argument that the language is so fucked up that
> this is unavoidable, so I do it now and we can discuss interesting topic).
> 
> I discussed that system with Rasmus Ledorf at afup 2012 and it something
> that D should definitively look into.
> 
> The const vs OOP discussion have shown once again that D will have to
> introduce breaking changes in the language. This isn't easy matter
> because if we break people code, D isn't attractive. But as long as code
> isn't broken, D people can't worked on what's next and it slows down D
> progress.
> 
> The system adopted in PHP works with a 3 number version. The first
> number is used for major languages changes (for instance 4 > 5 imply
> passing object by reference when it was by copy before, 5 > 6 switched
> the whole thing to unicode).
> 
> The second number imply language changes, but either non breaking or
> very specific, rarely used stuff. For instance 5.2 > 5.3 added GC,
> closures and namespace which does not break code.
> 
> The last one is reserved for bug fixes. Several version are maintained
> at the same time (even if a large amount of code base is common, so bug
> fixes can be used for many version at the time).
> 
> We should leverage the benefit of having switched to git to go in that
> way. We can start right now D2.1.xx with the opX dropped from object and
> see how it goes without requiring everybody to switch now.
> 
> Such a system would also permit to drop all D1 stuff that are in current
> DMD because D1 vs D2 can be chosen at compile time on the same sources.
> 
> git provide all we need to implement such a process, it is easy to do it
> soon (after 2.060 for instance) because it doesn't imply drastic changes
> for users.

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.

Once the language is stable enough that we expect pretty much anything written 
now to work several years from now, _then_ providing a more advanced 
versioning scheme would probably be beneficial. But much as D is far more 
stable than it was a year or two ago, there's still enough in flux that I don't 
think that there's much point in switching versioning schemes like that.

- Jonathan M Davis


More information about the Digitalmars-d mailing list