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