View mode: basic / threaded / horizontal-split · Log in · Help
July 12, 2012
D versionning
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.
July 12, 2012
Re: D versionning
food for thought:

http://semver.org/
July 12, 2012
Re: D versionning
On Thu, Jul 12, 2012 at 8:49 PM, deadalnix <deadalnix@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.
>

Definitely +1!!!

-- 
Bye,
Gor Gyolchanyan.
July 12, 2012
Re: D versionning
> 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.


We can also learn from the python community, whose from 
__future__ import <feature> facility is a great success and we 
should adopt a similar scheme.

Consider the -property switch or a future introduction of tuple 
syntax.
If you start a new project, it's no problem. Just use the switch 
and don't
introduce things that will not work without. But if you have an 
old codebase
but want to use a new feature you can either

a) fix the hole codebase at one
b) fix and configure your build systems to build some files with 
and some files without the switch.

Both options are PITA. An alternative is to introduce 
#pragma(future, tuplesyntax);

Now you can insert the pragma in those sourcefiles that are new 
or already fixed and you can immediately benefit from the feature 
and you can upgrade your code file by file or even scope by scope.

Later versions could even introduce #pragma(past, notuplesyntax) 
before dropping the old syntax completely.
July 12, 2012
Re: D versionning
On 12/07/2012 19:10, Tobias Pankrath wrote:
>> 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.
>
>
> We can also learn from the python community, whose from __future__
> import <feature> facility is a great success and we should adopt a
> similar scheme.
>
> Consider the -property switch or a future introduction of tuple syntax.
> If you start a new project, it's no problem. Just use the switch and don't
> introduce things that will not work without. But if you have an old
> codebase
> but want to use a new feature you can either
>
> a) fix the hole codebase at one
> b) fix and configure your build systems to build some files with and
> some files without the switch.
>
> Both options are PITA. An alternative is to introduce #pragma(future,
> tuplesyntax);
>
> Now you can insert the pragma in those sourcefiles that are new or
> already fixed and you can immediately benefit from the feature and you
> can upgrade your code file by file or even scope by scope.
>
> Later versions could even introduce #pragma(past, notuplesyntax) before
> dropping the old syntax completely.
>

This scheme don't allow for breaking change to be made. It also require 
the compiler to handle a mess of features that can be activated or not. 
This is way more work, and I don't really see the benefice.

As non breaking change are introduced in a different process than 
breaking one, it is easy to migrate to new version that will not break 
legacy code and provide new features.
July 12, 2012
Re: D versionning
On 12 July 2012 17:49, deadalnix <deadalnix@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!"


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
July 12, 2012
Re: D versionning
On 12/07/2012 19:31, Iain Buclaw wrote:
> On 12 July 2012 17:49, deadalnix<deadalnix@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.
July 12, 2012
Re: D versionning
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
July 12, 2012
Re: D versionning
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) ?
July 12, 2012
Re: D versionning
On Thu, 12 Jul 2012 14:57:31 -0700, deadalnix <deadalnix@gmail.com> wrote:

> 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.

This. 1000% this. New functionality is fundamentally different and placing  
bug fixes in the same development cycle is ridiculous to the point that no  
successful software endeavor I know of to date has ever considered it a  
viable strategy much less promoted it's use. I don't necessarily WANT to  
upgrade my DMD all the time to the latest, but I have on choice to get the  
latest set of bugfixes. It would also make the task of adding new features  
much simpler, you can pull the fix merges into both trees, and maintain a  
stable branch, a development branch. You'll note that the versioning  
system tends to work well with this model.

For example:
2.0.60 is the current HEAD. Bug fixes Only.
2.1.60 is the new feature branch. It is a GitHub fork of the current  
DMD-HEAD owned by the same org as current DMD-HEAD. This way Walter can  
work against both simultaneously.

We could have rolled the Object const change in 2.1.60, found out we  
didn't like them but instead of being FORCED to revert it to keep 2.060  
stable, we could have continued developing and improving the model or  
working on the problem from a completely different angle, WITHOUT  
affecting the release of 2.0.60.

We could keep all the COFF work in the DMD 2.1 branch without affecting  
DMD 2.0 branch and having nearly as many breakages as we currently do in  
HEAD. Most recently, the ElfObj breakage. Roll that work into 2.1.60 and  
if it breaks well, you KNEW you were on the development branch, what's  
your problem?

The stable/development branch model exists for a reason, it works, well.  
We don't have to keep rediscovering the models that worked successfully  
for other teams the hard way. If we proactively seek best practices, we  
can proactively avoid a huge amount of pain.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home