moving away from changelog.dd?

foobar foo at bar.com
Wed Dec 26 03:43:32 PST 2012


On Tuesday, 25 December 2012 at 19:44:41 UTC, Walter Bright wrote:
> On 12/25/2012 11:19 AM, Jonathan M Davis wrote:
>> On Tuesday, December 25, 2012 04:18:10 Walter Bright wrote:
>>> On 12/25/2012 3:41 AM, Jonathan M Davis wrote:
>>>> I think that that's what most of us are agreed upon at this 
>>>> point. What is
>>>> currently the WHATSNEW section will continue to be done by 
>>>> hand, but the
>>>> LIBBUGSFIXED section will be autogenerated.
>>>
>>> WHATSNEW is a list of new features, which are (or should be) 
>>> in bugzilla as
>>> enhancement requests.
>>
>> So, if we put a new module through the review process, we're 
>> going to go and
>> create an ehancement request for it after the fact just so 
>> that it's in
>> bugzilla and shows up in the automatically generated changelog?
>
> Yes. Recall that there are a pretty small number of these, so 
> it's fair to compromise on this.
>
>> That seems off
>> to me. Bugzilla is for reporting bugs or requesting that 
>> things be added to
>> the language or library, not for reporting everything that we 
>> do.
>> The SCM log is for that.
>
> That log is pretty useless for anyone who wants a list of bug 
> fixes and new features, as it is full of commits that are 
> irrelevant to users.
>
>
>> Also, some of those sorts of changes should probably get more 
>> prominence than
>> they're likely to get in the middle of a list of bugzilla 
>> issues, or they may
>> require further explanation.
>
> Full explanations were never what the changelog was for, that's 
> why it is a list of clickable links.
>
>> And it's not like it takes much time or effort to maintain the 
>> the WHATSNEW
>> section, as it's much smaller than the bug fix section.
>
> Nor does it take much time or effort to add 3 enhancement 
> requests to Bugzilla for new modules.
>
>
>>> Various musings, rationales, future changes, etc., should go 
>>> in a separate
>>> document called releasenotes.
>>>
>>> I don't think it's viable to have a document half-generated 
>>> automatically
>>> and half-editted by humans.
>>
>> I really don't see why not. The section with new stuff gets 
>> written by hand and
>> the bug fix section gets created with a bugzilla query. What's 
>> so hard about
>> that?
>
> Sure it's possible, but I prefer to keep the complexity down of 
> generating the site. Also, releasenotes and changelog serve 
> different purposes, it makes sense to have them be separate 
> documents. (A future change is NOT a change to the current 
> release.)
>
>
>> I don't think that we've been having any problems whatsoever 
>> dealing
>> with the WHATSNEW section.
>
> Yes, we have. Things have frequently been omitted.

It seems everyone agrees there need to be an automated changelog 
and a hand written release-notes. I don't see a point to continue 
bikeshading whether they belong in a single document or two 
separate ones. Just pick the one that is easiest to implement! We 
can always add a link to the changelog from the release-notes to 
satisfy those that want a single document.

The more important issue is whether to add bugzilla entries after 
the fact and whether the changelog should be geberated from Git 
or bugzilla.
In the _current_ state of affairs yor (walter) are correct that 
relying on git log messages will be useless. BUT, this is only 
another symptom of the current broken process.
The CORRECT way to implement this would be to take the actual 
changes from the SCM (git) on the RELEASE branch (as opposed to 
the development branch) and filter it to only use MERGE commits. 
What that does is, it ignores all the intermediate development 
commits that are irrelevant.

Filling up bugzilla with entries that do not belong there 
shouldn't be the long term solution.


More information about the Digitalmars-d mailing list