View mode: basic / threaded / horizontal-split · Log in · Help
July 16, 2012
Re: D versionning
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
Re: D versionning
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
Re: D versionning
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
Re: D versionning
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
Re: D versionning
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
Re: D versionning
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
Re: D versionning
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
Re: D versionning
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
Re: D versionning
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
Re: D versionning
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.
9 10 11 12 13 14 15
Top | Discussion index | About this forum | D home