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 balancing "added". Let's drop it then.

      > I think the important marker itself is not important if you split out security/incompatible. If something new is important, bump the version number.

      I'd like to keep it because I'd like to be able to mark particular features as important, without tying myself to any particular scheme of version numbering.

      > 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.

      I changed "@" and "v" to "date" and "version" because none of the other tokens were single letters/symbols any more (as well as the overloading of "@" that I mentioned); it seems worthwhile to aim for consistency to improve simplicity, imho.

      > Can the markers be made case insensitive? I think people may like Version or SECURITY.

      Okay, as long as it's explicitly stated that conforming parsers must not attach any relevance to token case.