View mode: basic / threaded / horizontal-split · Log in · Help
July 16, 2012
Re: D versionning
On Monday, 16 July 2012 at 21:29:31 UTC, RivenTheMage wrote:
> On Monday, 16 July 2012 at 20:45:11 UTC, SomeDude wrote:
>
>> This way, the stable branch and the dev branch don't diverge 
>> to the point that there effectively become two versions of the 
>> same language.
>
> I think, they should be diverging.
>
> The stable branch should be "the TDPL branch". After reaching 
> point of TDPL-compliance (top priority for the branch), only 
> bugfixes and non-breaking features must be accepted (like COFF 
> support).
>
> The dev branch should be "the DMD3/TDPLv2 branch": a cutting 
> edge
> version of the D language.

I don't think so. I think it's the best way to split the 
community of users with the community of developers.
July 16, 2012
Re: D versionning
On Monday, 16 July 2012 at 21:29:39 UTC, SomeDude wrote:

> That's very precisely what the "rename" function of IDEs like 
> eclipse do, BTW.

The "upgrade mode" should be more than just textual
search-and-replace.
July 16, 2012
Re: D versionning
On Monday, 16 July 2012 at 21:34:45 UTC, RivenTheMage wrote:
> On Monday, 16 July 2012 at 21:29:39 UTC, SomeDude wrote:
>
>> That's very precisely what the "rename" function of IDEs like 
>> eclipse do, BTW.
>
> The "upgrade mode" should be more than just textual
> search-and-replace.

It's *not* textual search and replace. It's compiler checked 
semantic refactoring.
July 16, 2012
Re: D versionning
On Monday, July 16, 2012 23:29:30 RivenTheMage wrote:
> On Monday, 16 July 2012 at 20:45:11 UTC, SomeDude wrote:
> > This way, the stable branch and the dev branch don't diverge to
> > the point that there effectively become two versions of the
> > same language.
> 
> I think, they should be diverging.
> 
> The stable branch should be "the TDPL branch". After reaching
> point of TDPL-compliance (top priority for the branch), only
> bugfixes and non-breaking features must be accepted (like COFF
> support).
> 
> The dev branch should be "the DMD3/TDPLv2 branch": a cutting edge
> version of the D language.

We're talking about doing something similar to having 2.x.y, with the main 
branch incrementing x and the "stable" branch incrementing y. Going to v3 
would mean incrementing the 2. We have _no_ intention of doing that for years 
to come.

- Jonathan M Davis
July 16, 2012
Re: D versionning
On 7/16/12 5:33 PM, Jonathan M Davis wrote:
> We're talking about doing something similar to having 2.x.y, with the main
> branch incrementing x and the "stable" branch incrementing y.

That seems a simple, nice scheme.

Andrei
July 16, 2012
Re: D versionning
On 17/07/2012 00:33, Andrei Alexandrescu wrote:
> On 7/16/12 5:33 PM, Jonathan M Davis wrote:
>> We're talking about doing something similar to having 2.x.y, with the
>> main
>> branch incrementing x and the "stable" branch incrementing y.
>
> That seems a simple, nice scheme.
>
> Andrei

That is the scheme proposed in the very first post. It has been used 
successfully in many projects.
July 16, 2012
Re: D versionning
On 16/07/2012 23:26, SomeDude wrote:
> On Monday, 16 July 2012 at 14:28:45 UTC, Jesse Phillips wrote:
>> On Monday, 16 July 2012 at 06:05:43 UTC, Walter Bright wrote:
>>
>>> I've had a lot of my own working D code break because of name changes
>>> in Phobos. This is extremely annoying. I can fully understand that it
>>> drives people away. It's got to stop.
>>
>> Name changes have been the least annoying breaking change I've come
>> across from using D. Language design being the biggest.
>>
>> Luckily I've expected that, and recently hit has been very infrequent.
>> There are still changes that will be making big ripples (actually
>> maybe not so much if we are changing how we handle toHash...). Maybe
>> this unstable branch thing will allow us to make a bunch of a breaking
>> changes together when we have one of these required disruptions.
>
> I don't think the unstable branch should give you the false idea that
> you are free to make breaking changes, because in the end, they will be
> incorporated in the stable branch, breaking code, or the users will be
> stuck. So although there may be *some* breaking changes, they should
> stay relatively limited. Each breaking change should increment the x
> number in the 2.x.y scheme. So if the x moves too quickly, the stabe and
> unstable branches will quickly diverge to become unreconciliable.
>

This is exactly the reason why the 3 digit versionning system exists.
July 17, 2012
Re: D versionning
+1 for a "2.breaking.bugfix" scheme.  I've used this scheme on 
anything serious for years, and know many others who have; so it 
is not only popular but also quite tried and proven.  Not for 
every project, of course (although I don't understand why the 
Linux kernel team dropped it with 3.x), but for the majority it 
seems to work wonders.

Rest of the thread seems like so much unnecessary politic.
July 17, 2012
Re: D versionning
On Monday, 16 July 2012 at 22:14:03 UTC, Jonathan M Davis wrote:

> Going to v3 would mean incrementing the 2.
> We have _no_ intention of doing that for years
> to come.

Small steps are perfect for many projects, but - in my opinion -
not for a programming language specification (and reference 
implementation). Big leaps are better.

Look at C# - 2.0, 3.0, 4.0...

I'm aware of counterexamples (like PHP), but these are bad
examples to follow.
July 17, 2012
Re: D versionning
On Tuesday, July 17, 2012 06:37:23 RivenTheMage wrote:
> On Monday, 16 July 2012 at 22:14:03 UTC, Jonathan M Davis wrote:
> > Going to v3 would mean incrementing the 2.
> > We have _no_ intention of doing that for years
> > to come.
> 
> Small steps are perfect for many projects, but - in my opinion -
> not for a programming language specification (and reference
> implementation). Big leaps are better.
> 
> Look at C# - 2.0, 3.0, 4.0...
> 
> I'm aware of counterexamples (like PHP), but these are bad
> examples to follow.

Actually, most programming languages are very conservative in how often they 
break existing code. And as I understand it (I haven't used C# much), C# 
doesn't break a lot of code either. They mostly just add more stuff on top of 
what they did before and then try and get you to use the new stuff in addition 
to the old stuff (or instead of, depending on what it is). But the old stuff is 
still there.

We'll continue to add new features to Phobos for the forseeable future as long 
as those features are worth adding. And while I don't expect that we'll add 
very many language features to D or that they'll be added very quickly, non-
breaking additions will still occur from time to time. However, _breaking_ 
changes to the language should be pretty much non-existent for _years_ to 
come, and breaking changes to Phobos should become quite rare if not non-
existent as well.

We'll eventually look at starting D3, which will mean breaking core language 
stuff where we deem appropriate and possibly completely revamping stuff in 
Phobos, but D2 needs to become fully stable and get a solid user base _long_ 
before we'll consider pulling the rug out from everyone with D3.

- Jonathan M Davis
10 11 12 13 14 15
Top | Discussion index | About this forum | D home