July 12, 2012
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
food for thought:

http://semver.org/

July 12, 2012
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
> 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
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
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
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
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
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
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 6 7 8 9 10 11
Top | Discussion index | About this forum | D home