Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ethan (3163)

  reversethis-{ed. ... rap.nov.olissat}

Being a 25-year old chap living in the western-most town of Germany. Stuying communication and information science and being a huge fan of XS-related things.

Journal of ethan (3163)

Tuesday May 13, 2003
04:03 AM

Uselessnes of Changelogs

[ #12161 ]

I just saw that a new Mail::SpamAssassin release has hit the CPAN. Unfortunately I am unable to conclude from the changelog whether I should upgrade or not. Can anyone but the developpers themselves learn anything from this?

        2003-05-10 20:38 felicity

                * Changes: Updated for 2.54rc1

        2003-05-10 18:05 duncf

                * lib/Mail/ Ready to release?

        2003-05-10 17:34 felicity

                * rules/:,,,
          ,, bug 1891:
                    RCVD_IN_VISI is no longer available

For me this is as interesting and enlighting as reading CVS log messages which the above probably are.

Please, people out there, provide sane Changelogs for the end-user and not for yourselves!

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I really like your point.

    Write the CHANGES file for your audience and not for yourself.

    You write a manual, you write POD, you write code, you write tests, you write a piece of software with audience in mind, then when it comes to the CHANGES file - all this changes and things get very simplified and incomprehensible (at least in your example).

    I will go over my changes file to see whether I make the same mistake.
    • Re:Good point (Score:3, Informative)

      More precisely, provide a CHANGE file for users and a ChangeLog for developers.

      I like the Writing log messages guidelines from Subversion's HACKING [] internal guide.

      But sometimes, log messages that are just plain funny [] are sufficient.

      • More precisely, provide a CHANGE file for users and a ChangeLog for developers.

        Perl is doing this wonderfully, I think. The various Changes* files are useful for the porters while the end-user gets a polished perldelta that is articulate, pleasant to read and always contains some additional bits of interest. The perldeltas are one of the things I always keep looking forward to when it comes to new Perl releases (I wonder whether there'll be a perldelta6).