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.

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.

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.

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

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

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.

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.

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

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.

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