D 1.076 and 2.061 release

Walter Bright newshound2 at digitalmars.com
Thu Jan 3 19:18:25 PST 2013


On 1/3/2013 12:27 PM, Leandro Lucarella wrote:
> BTW, Changelogs looks extremely naked now, I think release notes are
> really needed now. Al least for new features. Is far from ideal to make
> people go through a bug report to know how they can adapt their code to
> new features.

On the other hand, the older way of doing changelogs routinely missed a *lot* of 
things. Relatively few people doing the pulls would bother to log the changes. I 
think there were easy double the number of changes showing up in the search than 
were in the log.


> And sometimes bug reports are not updated on how things turned out, for
> example #7041[1], a feature I implemented myself. The bug report is
> outdated AFAIK, the title talks about a -di flags which doesn't even
> exist, you actually have to go through the pull request[2] to see what
> the hell is going on. And even then the behaviour of that pull request
> was changed in a subsequent one[3], and there are no visible links
> between those 2 pull requests.

Please update that bugzilla issue. As I posted elsewhere in this thread, this 
method does require upping our game with bugzilla tags, titles, and descriptions.

I don't see that it is any *harder* to update the bugzilla issue than it is to 
provide a brief summary in the changelog.

As for what's new, the failure here is the failure to document those changes. 
This is not a failure of the changelog - it's a failure of the documentation 
pages. The bugzilla should have a link to the relevant documentation.

I do *not* think that a changelog new feature entry takes the place of updating 
the documentation, and I do not agree with writing the documentation twice 
(changelog and documentation).


> Anyway, at least for this particular change, the changelog is basically
> useless, and I don't think the bug report is the right place to inform
> users about compiler changes.

We've been using bugzilla for a long time to organize enhancement requests.

> Users don't care about the history and
> discussion around a change, they just only want to know how to take
> advantage of new features and how to fix their code (possibly with some
> exceptions of course, in which case they can still go back to the bug
> report and pull requests).

I agree this new system is imperfect - but I argue it is better than what we 
were doing before.



More information about the Digitalmars-d-announce mailing list