July 16, 2012
On 7/16/12 4:37 PM, SomeDude wrote:
> The 2.060 is late, very late.

Then perhaps it's worth priming dlang-stable with a "2.059 plus best of 2.060" experimental release. Enough to only get a few essential commits in. It would help the project get its bearings.

Andrei
July 16, 2012
On Sunday, 15 July 2012 at 23:15:29 UTC, deadalnix wrote:
> On 15/07/2012 23:36, SomeDude wrote:
> Well bug will be fixed for sure.
>
> But, as explained, as new feature are also introduced, bug will also be introduced.
>
> This is why stable release is never reached.

I ended up changing my mind, but only if the minor releases don't get distanced by the major releases, i.e if the features that have proven to be stabilized after a while end up being merged in the stable branch, i.e the stable branch is not frozen.

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.
July 16, 2012
On Mon, 16 Jul 2012 13:42:36 -0700, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 7/16/12 4:37 PM, SomeDude wrote:
>> The 2.060 is late, very late.
>
> Then perhaps it's worth priming dlang-stable with a "2.059 plus best of 2.060" experimental release. Enough to only get a few essential commits in. It would help the project get its bearings.
>
> Andrei

I should note that dlang-stable is currently forked from DMD-HEAD, so you'd have to reset it to the 2.059 tag then start merging commits, doable, but a lot of work.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 16, 2012
On Mon, 16 Jul 2012 13:45:10 -0700, SomeDude <lovelydear@mailmetrash.com> wrote:

> On Sunday, 15 July 2012 at 23:15:29 UTC, deadalnix wrote:
>> On 15/07/2012 23:36, SomeDude wrote:
>> Well bug will be fixed for sure.
>>
>> But, as explained, as new feature are also introduced, bug will also be introduced.
>>
>> This is why stable release is never reached.
>
> I ended up changing my mind, but only if the minor releases don't get distanced by the major releases, i.e if the features that have proven to be stabilized after a while end up being merged in the stable branch, i.e the stable branch is not frozen.
>
> 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.

That is the main goal of dlang-stable. :-)

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 16, 2012
On Mon, Jul 16, 2012 at 04:42:36PM -0400, Andrei Alexandrescu wrote:
> On 7/16/12 4:37 PM, SomeDude wrote:
> >The 2.060 is late, very late.
> 
> Then perhaps it's worth priming dlang-stable with a "2.059 plus best of 2.060" experimental release. Enough to only get a few essential commits in. It would help the project get its bearings.
[...]

+1.


T

-- 
Famous last words: I wonder what will happen if I do *this*...
July 16, 2012
On Sunday, 15 July 2012 at 23:36:56 UTC, Patrick Stewart wrote:
>
> 100% passage of test suites do not make me more happy even a bit. Which is my business, of course.
>
> What would make me happy is feature list on page describing milestones. And each version branched and kept stable, with bugfixes and *no* new features introduced.
>
> Real question is where is D going? When will be enough with cramming new features down its throat each time a semi-good idea pops up? When will D leave beta and reach v1 ? Because D2 is still in beta as far as I see it.

Seriously, your whining is getting tiring and will give you nothing.
July 16, 2012
On Monday, 16 July 2012 at 20:47:13 UTC, Adam Wilson wrote:
>> I ended up changing my mind, but only if the minor releases don't get distanced by the major releases, i.e if the features that have proven to be stabilized after a while end up being merged in the stable branch, i.e the stable branch is not frozen.
>>
>> 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.
>
> That is the main goal of dlang-stable. :-)

Then I guess we agree :)
July 16, 2012
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.

July 16, 2012
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.
July 16, 2012
On Monday, 16 July 2012 at 08:12:39 UTC, Jacob Carlborg wrote:
> On 2012-07-16 08:51, Walter Bright wrote:
>
>> It is a good idea, but I'd be nervous myself about allowing the compiler
>> to edit my code :-)
>
> Don't you trust your own compiler :)
>
> The compiler could have --dry-run option to show what would be changed. It could also show a diff after all processing.

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