D versionning

Paulo Pinto pjmlp at progtools.org
Fri Jul 13 00:41:36 PDT 2012


"deadalnix"  wrote in message news:jtn1ol$juu$1 at digitalmars.com...

On 12/07/2012 19:31, Iain Buclaw wrote:
> On 12 July 2012 17:49, deadalnix<deadalnix at gmail.com>  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.
>
> Might as well just say "Lets start D3 now - Let's drop all features
> that have been deprecated since 0.103 - everyone make a hype and
> party!"
>
>

> No, user will need backward compatible support for any real life work.

This is why besides some small D toy projects, I keep using C++(11) for any 
native coding at work
when the oportunity surfaces.

While I keep complaining on Go forums that I don't like that the language 
lacks enums and
generics, the way Google oposes language featuritis and is keen on Go 1 
stability, makes it easier
to sell to management.

--
Paulo 



More information about the Digitalmars-d mailing list