D 1.076 and 2.061 release

[Leandro Lucarella]

Walter Bright, el  3 de January a las 23:03 me escribiste:
> On 1/3/2013 9:49 PM, Jonathan M Davis wrote:
> >but other lines like
> >
> >$(LI std.string: $(RED The implementations of std.string.format and
> >string.sformat have been replaced with improved implementations which conform
> >to writef. In some, rare cases, this will break code. Please see the
> >documentation for std.string.format and std.string.sformat for details.))
> 
> Yes, you can put this in as the bugzilla title, though I'd tighten it up a little.

Are you being serious? Do you really think this would be useful for the
user?  That the user will be able to spot that particular comment among
hundreds of bugs in a bugzilla search query result?

Is really that hard to acknowledge that release notes are better than
doing that? I can understand if you see problems on keeping up to date
the release notes, but I can't believe that anyone can think is plain
better to user bugzilla instead (for the user POV at least).

Can we at least agree on that and then see if is feasible to have good
and up to date release notes?

> >$(LI std.range.hasSlicing has been made stricter in an effort to make it more
> >reliable. opSlice for infinite ranges must now return the result of
> >std.range.take, and any range with slicing which supports $(D $) must now
> >support it with the same semantics as arrays (including supporting subtraction
> >for finite ranges).)
> 
> This is 3 separate enhancements, each of which should be its own
> issue, and will certainly fit as the issue title.

You are missing the point, and even then, from the user POV, is much
nicer to have all that information together, because even if they are
separated issues from a bug report POV, they are related to the user.

> >Automating the bug list is fine, but don't throw away all of the non-bugzilla
> >stuff that we've been putting in the changelog.
> 
> Nothing has been deleted. In fact, I think those previous items in
> the 2.060 New/Changed Features are seriously deficient because they
> contain no hyperlinks for more information.

This have to be fixed in the review process! A change shouldn't be
merged unless it has proper documentation!

> But, as I mentioned to Leandro, if someone wants to add some
> additional notes to the changelog file, that's great. But somebody
> has to do the work, and in the past there generally hasn't been much
> effort expended there.
> 
> Me, I've spent more time than I care to think about keeping that
> list manually updated, badly.

I understand that, but I don't think that work should be optional and
only done if somebody feels like. Every pull request should include
proper documentation update. Can we try to focus on that for the next
release?

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Spooker3 always wanted to learn russian...but learned C++ instead :)