August 19, 2014
On 8/18/14, 5:23 PM, Nick Sabalausky wrote:
> On 8/18/2014 7:14 PM, Dicebot wrote:
>>
>> I also propose to start 2.067 beta branch right now and declare it yet
>> another bug-fixing release.
>
> Seconded.

Well that's what happened - someone started 2.067. What's the advantage of doing this? Now we need to worry about master and 2.067 instead of just master. -- Andrei

August 19, 2014
On Tuesday, 19 August 2014 at 04:26:48 UTC, Andrei Alexandrescu wrote:
> Well that's what happened - someone started 2.067. What's the advantage of doing this? Now we need to worry about master and 2.067 instead of just master. -- Andrei


Well, what you do at that point is just fix all of the regressions on the branch, and when it's ready you do another release. You don't put anything else on it. All of the normal dev work goes on master. And some point after the branch has been released as the next release, you branch again.

Now, unless we have enough regressions on master that it's going to take us over a month to fix them, I think that branching right after releasing is a bit much, though if some of the regressions are bad enough, maybe it would make sense to release faster. And given how long we've been trying to get 2.066 ready after branching it and how much work has been done on master since then, maybe it makes sense. I don't know.

I would have thought though that we'd aim to branch something like 2 to 4 weeks after releasing and then take about a month to make sure that all regressions are fixed so that we get a release about every two months. All the major dev work just continues on master, and it'll end up on a branch about every two months staggered from when that branch gets released as an official release.

Certainly, aiming for something along those lines would get us faster releases than we've been doing. We've been waiting way too long to branch and then been rather slow about getting through all of the regressions. By branching earlier, we should be able to release more quickly.

- Jonathan M Davis
August 19, 2014
Who could help with translation change logs to russian and publication it's on LOR?
August 19, 2014
On Tue, 19 Aug 2014 05:24:54 +0000
Suliman via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

> Who could help with translation change logs to russian and publication it's on LOR?
DYI.


August 19, 2014
On Tue, 19 Aug 2014 05:24:54 +0000
Suliman via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

> Who could help with translation change logs to russian and publication it's on LOR?
sorry, i mean DIY. ;-)


August 19, 2014
I remember that it was planned to add functional future for iteration throw elements. Something like:
().times
().do

But I can't find original post about it and nothing related in changelogs...
August 19, 2014
On 18/08/14 22:43, Vladimir Panteleev wrote:

> I agree, I am also surprised that 2.066 was released despite the
> regressions.

Same here.

> How is it decided when it's time to cut off a new release? Do we have
> two RCs and that's it?

It seems Andrei/Walter is very stressed to get the release out.

-- 
/Jacob Carlborg
August 19, 2014
On 18/08/14 21:00, Andrei Alexandrescu wrote:
> Congratulations to everyone involved!
>
> http://www.reddit.com/r/programming/comments/2dwqvy/d_2066_nogc_c_namespaces_multidimensional_slices/
>
>
> https://www.facebook.com/dlang.org/posts/905593426121006
>
> https://twitter.com/D_Programming/status/501443132115140609

Did someone finish the changelog?

-- 
/Jacob Carlborg
August 19, 2014
On Tuesday, 19 August 2014 at 05:03:40 UTC, Jonathan M Davis wrote:
> On Tuesday, 19 August 2014 at 04:26:48 UTC, Andrei Alexandrescu wrote:
>> Well that's what happened - someone started 2.067. What's the advantage of doing this? Now we need to worry about master and 2.067 instead of just master. -- Andrei
>
>
> Well, what you do at that point is just fix all of the regressions on the branch, and when it's ready you do another release. You don't put anything else on it. All of the normal dev work goes on master. And some point after the branch has been released as the next release, you branch again.
>
> Now, unless we have enough regressions on master that it's going to take us over a month to fix them, I think that branching right after releasing is a bit much, though if some of the regressions are bad enough, maybe it would make sense to release faster. And given how long we've been trying to get 2.066 ready after branching it and how much work has been done on master since then, maybe it makes sense. I don't know.
>
> I would have thought though that we'd aim to branch something like 2 to 4 weeks after releasing and then take about a month to make sure that all regressions are fixed so that we get a release about every two months. All the major dev work just continues on master, and it'll end up on a branch about every two months staggered from when that branch gets released as an official release.
>
> Certainly, aiming for something along those lines would get us faster releases than we've been doing. We've been waiting way too long to branch and then been rather slow about getting through all of the regressions. By branching earlier, we should be able to release more quickly.
>
> - Jonathan M Davis

In that case, shouldn't it be 2.066.1?
August 19, 2014
>http://dlang.org/changelog.html
>Version D 2.066 August 18, 2014
>...
>Phobos enhancements
>  1.Bugzilla 3780: getopt improvements by Igor Lesik

Sorry, i can't find this improvements nor in getopt.d nor in http://dlang.org/phobos/std_getopt.html.

Is this announce prematurely, and that this changes will be seen in 2.067 ?