D 1.076 and 2.061 release

[Jonathan M Davis]

On Thursday, January 03, 2013 19:10:59 Walter Bright wrote:
> On 1/3/2013 11:36 AM, Jonathan M Davis wrote:
> > Oh. Those are links. I was wondering when the data was actually going to
> > be
> > posted. When compared to the previous ones, it looks like there's only
> > headers with no information.
> 
> The idea is to add explanatory information to the bugzilla issue being
> pointed to.
> 
> Making some effort to clarify the title of the bugzilla issue is also
> justified.
> 
> This change to the changelog presentation does require that we up our game
> with bugzilla - accurate tags (you can see at the top what is being keyed
> on), accurate titles, and accurate information.

No offense, but that doesn't cut it. Maybe it makes sense to create bugzilla 
entries for stuff like 

$(LI std.digest.ripemd: Added RIPEMD-160 digest implementation.)

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

or

$(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).)

are purely notes which developers should be made aware of which should _not_ 
be buried in a list of bugzilla entries where most people won't see them (not 
to mention, how many people do you think actually read through that list of 
bug fixes; I think that it's mostly the notes that were at the top which people 
cared about, and now they're gone).

If you want to have a "release notes" section for them separate from the 
changelog section, fine. But these are notes which should be relatively 
prominent so that people see them! And they're specifically notes for people to 
read and not enhancement requests or bug fixes or whatnot. In your zeal to 
automate the bug fix list, you're throwing away something of real value.

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.

- Jonathan M Davis