use Perl

• Restating thoughts (Score:2)

  by Juerd (1796)

  "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.
  • Re: (Score:1)

    by hex (3272)

    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
  • Re: (Score:2)

    by bart (450)

    "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.
    • Re: (Score:2)

      by Juerd (1796)

      Incompatible, in a changelog, means: you should anticipate breakage caused by this change.
      
      Pure additions typically never break existing code.
• Maintainer? (Score:1)

  by jtrammell (6222)

  I'm curious why "maintainer" is the only token that's abbreviated. Maybe "owner", if length is the issue?
  • Re: (Score:1)

    by hex (3272)

    Good catch. Fixed.
  • Re: (Score:1)

    by hex (3272)

    Although come to think of it, "docs" is an abbreviation, really... :-)
    • Re: (Score:1)

      by jtrammell (6222)

      Indeed!
• hmm! (Score:1)

  by Alias (5735)

  all!:
  those!:
  exclamation!:
  marks!:
  look!:
  really!:
  weird!:
  
  
  • Re: (Score:1)

    by hex (3272)

    They're meant to stand out.
• Some comments ... (Score:2)

  by drhyde (1683)

  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
  • Re: (Score:1)

    by hex (3272)

    > 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
    • Re: (Score:2)

      by drhyde (1683)

      Furrfu! You don't expect programmers to read the documentation do you? :-)
  • Re: (Score:2)

    by Juerd (1796)

    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.)
    • Re: (Score:1)

      by hex (3272)

      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.