D 1.076 and 2.061 release

Pierre Rouleau prouleau001 at gmail.com
Fri Jan 4 08:59:43 PST 2013


On 13-01-04 3:45 AM, Walter Bright wrote:
> On 1/4/2013 12:16 AM, eles wrote:
>> Two concrete examples:
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=5992
>>
>> is described in the list as: " Phobos Win64 - D2 "; At least, change
>> its title
>> to something more human, like "Win64 alpha has been released with working
>> Phobos." (yes, that's exactly Don's comment, but at the end of the
>> discussion).
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=5269
>>
>> is described as: "version(assert)". Only if you read the discussion you
>> understand that "version(unittest) that allows setup code for assertions
>> to run when assertions are enabled and be compiled out when assertions
>> are
>> disabled" was implemented.
>>
>> It is very different thing to see "version(assert)" and reading a
>> meaningful
>> description of it...
>
> I understand and agree. And, as I posted previously, anyone can fix the
> issue titles. I've already fixed a few.
Don't you think a process that requires reviewing these titles *before* 
the actual software release announcement posting would help?

Would it not be useful to have a person in charge of the redaction of 
this type of software release? That person would be able to review all 
Bugzilla reports that have been automatically generated and create a 
separate document titled "What's new in D 2.xxx" that would provide an 
overview of the release.  Of course the existing four lists (new/changed 
features, DMD bugs fixed,...) would still exists and would be reachable. 
  But this new document would present all the information about the 
changes, their intent, the way they interact together and influence 
writing D code.  That document itself would be created during the same 
development cycle than the code itself.  And would be reviewed.

Having this document might be seen as duplication of information.  It 
can also be seen as a central idea repository for the presentation of 
the changes/fixes of the release and the activity leading to the 
creation of this document could generate extra discussions that may lead 
to new ideas and more bugs being fixed.  It would help introduce the 
information to users and if anyone is interested in the details then 
they can always go to the actual Bugzilla entries listed the way they 
are now.

As an example of what I am thinking about, see 
http://docs.python.org/2/whatsnew/2.7.html

Note, in that document the links to the various issues.  The 4 lists of 
Bugzilla issues could be located at the top of the release document.

/Pierre




More information about the Digitalmars-d-announce mailing list