Opened 12 years ago

Closed 12 years ago

#408 closed discussion (fixed)

Using gnuify-changelog.pl ... or re-think how ChangeLog should be maintained.

Reported by: Peter Owned by: Jari Häkkinen
Priority: trivial Milestone: yat 0.5
Component: build Version: trunk
Keywords: Cc:

Description (last modified by Jari Häkkinen)

The current Changelog format is a pain to update for the Release Manager. Shall we use the guify-changelog.pl instead and parse the changelog from the repository (svn log). In that way it could be automatically done within make dist.

In short, the ChangeLog is very tedious to keep up-to date. Change format or updating procedure.

Change History (11)

comment:1 Changed 12 years ago by Jari Häkkinen

Description: modified (diff)
Summary: using gnuify-changelog.plUsing gnuify-changelog.pl ... or re-think how ChangeLog should be maintained.

comment:2 Changed 12 years ago by Peter

I tried the script again and the size of the output is 116kB. Although that is not tremendously large I think it is waste to increase the dist with 116kB. I simply don't see the use of the file anymore. Just like with the TODO file it is not useful because when you need the information you'll go to trac. Or in the log case you will likely issue svn log if you are in a svn wc. This, of course, assumes that you have access to the web and I think that is pretty much true for most people for most of the time.

Therefore I think the Changelog should change to something that looks more like the TODO file. Something static that doesn't cause headache for the RM and simply direct the reader to the trac site.

comment:3 Changed 12 years ago by Peter

A suggestion:

See the yat trac environment for log information:

http://dev.thep.lu.se/yat/log

comment:4 Changed 12 years ago by Peter

An alternative could be to keep it more similar to current style, but avoid referring to revisions and rather refer to tags. For instance:

http://dev.thep.lu.se/yat/log/tags/0.4.2?mode=follow_copy

comment:5 Changed 12 years ago by Peter

(In [1798]) refs #408

Changing pointers in ChangeLog? so they are easier to maintain.

comment:6 Changed 12 years ago by Peter

I hope the change in r1798 is OK with everyone.

Left is to decide is how ChangeLog should look in the release tarball. I see three alternatives:

  1. Use the perl-script as suggested above to create a ChangeLog at release time. This is how GNU CoreUtils does it this way with a dist-hook (see Makefile.am).
  1. Keep the distributed ChangeLog the same as the one in the repository. It is good to keep the repository and distributed tarball as similar as possible.
  1. At release time use a dist-hook that generates ChangeLog with pointers to the specific release. See source:trunk/ChangeLog and it is a trivial exercise to print that file with the specific <VERSION> since version info is available in make variable $(VERSION)

comment:7 in reply to:  6 ; Changed 12 years ago by Jari Häkkinen

Replying to peter:

I hope the change in r1798 is OK with everyone.

Perfect ... I think. One thing (there is always one), the output is very verbose. Is it possible to generate a log without all changed files specified?

I begin to rethink my perfect statement above. The changes are not grouped to releases, all 0.4 logs are a part of the 0.4.1 log. Of course, they are but one would like to highlight the difference between 0.4.1 and 0.4. Now you may say that this information should go into NEWS, and as always, you are right. I am back at Perfect!

Left is to decide is how ChangeLog should look in the release tarball. I see three alternatives:

  1. Use the perl-script as suggested above to create a ChangeLog at release time. This is how GNU CoreUtils does it this way with a dist-hook (see Makefile.am).
  1. Keep the distributed ChangeLog the same as the one in the repository. It is good to keep the repository and distributed tarball as similar as possible.
  1. At release time use a dist-hook that generates ChangeLog with pointers to the specific release. See source:trunk/ChangeLog and it is a trivial exercise to print that file with the specific <VERSION> since version info is available in make variable $(VERSION)

I think I prefer 2 with an amendment. The changelog could have specific version link to that release:

http://dev.thep.lu.se/yat/log/tags/0.4?format=changelog?mode=follow_copy for a 0.4 release http://dev.thep.lu.se/yat/log/tags/0.4.2?format=changelog?mode=follow_copy for a patch release.

In the trunk this link is naturally

http://dev.thep.lu.se/yat/log/trunk?format=changelog?mode=follow_copy for trunk

and it becomes a part of the release procedure to change this specific line.

comment:8 in reply to:  7 ; Changed 12 years ago by Peter

Replying to jari:

Replying to peter:

Left is to decide is how ChangeLog should look in the release tarball. I see three alternatives:

  1. Use the perl-script as suggested above to create a ChangeLog at release time. This is how GNU CoreUtils does it this way with a dist-hook (see Makefile.am).
  1. Keep the distributed ChangeLog the same as the one in the repository. It is good to keep the repository and distributed tarball as similar as possible.
  1. At release time use a dist-hook that generates ChangeLog with pointers to the specific release. See source:trunk/ChangeLog and it is a trivial exercise to print that file with the specific <VERSION> since version info is available in make variable $(VERSION)

I think I prefer 2 with an amendment. The changelog could have specific version link to that release:

http://dev.thep.lu.se/yat/log/tags/0.4?format=changelog?mode=follow_copy for a 0.4 release http://dev.thep.lu.se/yat/log/tags/0.4.2?format=changelog?mode=follow_copy for a patch release.

In the trunk this link is naturally

http://dev.thep.lu.se/yat/log/trunk?format=changelog?mode=follow_copy for trunk

and it becomes a part of the release procedure to change this specific line.

OK. you want tags to be identical to tarballs; makes sense. Would you mind amend as you desire?

comment:9 in reply to:  8 ; Changed 12 years ago by Peter

Replying to peter:

Replying to jari:

Replying to peter:

I think I prefer 2 with an amendment. The changelog could have specific version link to that release:

http://dev.thep.lu.se/yat/log/tags/0.4?format=changelog?mode=follow_copy for a 0.4 release http://dev.thep.lu.se/yat/log/tags/0.4.2?format=changelog?mode=follow_copy for a patch release.

In the trunk this link is naturally

http://dev.thep.lu.se/yat/log/trunk?format=changelog?mode=follow_copy for trunk

and it becomes a part of the release procedure to change this specific line.

OK. you want tags to be identical to tarballs; makes sense. Would you mind amend as you desire?

Second thoughts. One of the reasons behind this ticket was to avoid merge conflicts. If the file should have different versions in /tags and in /trunk it will automatically lead to conflicts. I am not happy about that because it implies extra work for the Merge Master.

comment:10 in reply to:  9 Changed 12 years ago by Jari Häkkinen

Replying to peter:

Replying to peter:

Replying to jari:

Replying to peter:

I think I prefer 2 with an amendment. The changelog could have specific version link to that release:

http://dev.thep.lu.se/yat/log/tags/0.4?format=changelog?mode=follow_copy for a 0.4 release http://dev.thep.lu.se/yat/log/tags/0.4.2?format=changelog?mode=follow_copy for a patch release.

In the trunk this link is naturally

http://dev.thep.lu.se/yat/log/trunk?format=changelog?mode=follow_copy for trunk

and it becomes a part of the release procedure to change this specific line.

OK. you want tags to be identical to tarballs; makes sense. Would you mind amend as you desire?

Second thoughts. One of the reasons behind this ticket was to avoid merge conflicts. If the file should have different versions in /tags and in /trunk it will automatically lead to conflicts. I am not happy about that because it implies extra work for the Merge Master.

I still vote for 2, even without changes suggested by me.

comment:11 Changed 12 years ago by Peter

Resolution: fixed
Status: newclosed

OK, then we are done here.

Note: See TracTickets for help on using tickets.