Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • "removed" is always also "incompatible". I don't think there is any need for having both.

    I don't particularly like "version" and "date". They're different in the sense that they must (or at least should) always come first, but now look like all the others. It's not a big deal, though. I really think this proposal is much better than the previous. It's good that you considered multiline items too.

    Can the markers be made case insensitive? I think people may like Version or SECURITY.
    • Copied from your comment on the first post...

      > As for the timestamp, you'd have two things, whitespace separated, instead of one. dateTtime may be the standard, but date time is much more commonly seen in the wild. And for a very good reason.

      Hm. I suppose it is meant to be a simple format. Okay - so long as the dates are yyyy-mm-dd[ hh:mm[:ss]] and nothing else, I can live with that.

      I suppose you're right about "removed", in a sense, as it is a feature-oriented label. I just got used to it bala

    • "removed" is always also "incompatible". I don't think there is any need for having both.

      I disagree. An addition is incompatible too. There's no harm in being a bit more specific!

      To me, "incompatible" means a change in how things are used: the functionality is still there, only, you'll have to try to achieve your goal in a slightly different manner: for example, using another function, or with a change in parameters.

      If older functionality is no longer available, that's more than just a change.

      • Incompatible, in a changelog, means: you should anticipate breakage caused by this change.

        Pure additions typically never break existing code.
  • I'm curious why "maintainer" is the only token that's abbreviated. Maybe "owner", if length is the issue?
  • all!:
    those!:
    exclamation!:
    marks!:
    look!:
    really!:
    weird!:

  • I prefer single characters instead of words; + and - for additions and removals (like diff); removal and other changes should be distinct because removal does *not* imply incompatible (see the example below).

    Any thoughts on how to deal with long text for any entry? I suggest that if a line starts with whitespace, it is assumed to be a continuation of the previous line:

    -: removed the dependency on Foo::Bar, which fails its tests on some platforms.
       It is now optional, and without it fr

    • > I suggest that if a line starts with whitespace, it is assumed to be a continuation of the previous line

      That'd be the part of the spec that says "A line beginning with \s+ is interpreted as the continuation of the preceding line" :-)

      Re your other points, I liked the single letters more too but people were keen on the whole word versions. I'll let them respond...

      I thought of maybe inventing a format for specifying bugtracker URLs but then it was getting a bit too complicated to merit the "simpli

    • That kind of removed is not the kind of removed I was thinking of. Such confusion is another reason to remove "removed" from the list.

      However, it does uncover a missing part of the changelog spec: a keyword for changes that are neither bugfixes nor incompatible, like backend changes (removed dependencies) and performance optimizations. I suggest "change" because it is nicely neutral. (I was thinking of "improvement" first, but it is too long and internals changes can be done for other reasons too.)
      • Actually, the first draft spec had "c" for "change" in it, and I think I dropped it by mistake when drawing up this new one. I agree that it should go back in.