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

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 have given this already some thoughts here: []

    What I came up with is a stream of yaml docs (separated by '---'), each containing a hash with info about that version. The reason to use a stream of separate docs is to cut back on indentation ("chrome"). So we only have one indentation level for the lists which means we can easily correct the format if somebody forgets to put the two spaces before the '- ' list token.

    Below is an example of how a Changes.yml could look like. I have refined some points. "api-stability" is a declaration if the author thinks that the API is powerful enough so it will only be added to, maintaining backward-compatibility on the API level. I hope the rest of the format is self-explanatory.

    version: 0.02                     # plain number or version string, required
    released-at: 2007-11-09           # datestring, required
    released-by: Roland Giersig <> # release author, required
    api-stability: draft              # stable | draft, required
    backward-compatibility: partial   # full | partial | none, required
    breaks-compatibility-in:          # list of subs, optional
      - foo()
      - bar()
    bugs-fixed:                       # list of bugs with references, optional
      - foo() crashes when given undef parameter <>
      - bar() should return "blah"
    major-new-features:               # list of text, optional
      - now also handles the BAZ protocol
    detailed-changes:                 # list of text, optional
      - rearranged arguments to foo()
      - changed return value of bar()
    version: 0.01
    released-at: 2007-09-05
    released-by: Roland Giersig <>
    api-stability: draft
    backward-compatibility: none
    license-changed-to: Artistic      # new license reference, optional
    maintainer-changed-to: RGIERSIG   # CPAN User Id of new maintainer, optional
    • I've seen your proposal and also thought about it.

      It seems a bit too detailed. Also I don't think that splitting the structure into different YAML streams for the sake of indentation is ideal. I don't mind indentation - after all, it's supposed to be machine-readable.

      If you really want a human-readable version as well, just have the YAML in Changes.yml and run:

      changes -f Changes.yml -ff >Changes

      By the way, more updates are coming. I've simplified the YAML somewhat (less indentation!) and added a

    • ...after all, it's supposed to be machine-readable...

      Sorry, but if you keep it that way, it won't get much ground. First and foremost, it should be conveniently human-writable, everything else comes afterwards. Because if you can't write it conveniently as a human, people won't use the format and stay with "unreadable" formats for Changes files. Having the Changes file generated from Changes.yml adds complexity to the build process which is somewhat acceptable if it's easily (1 line in Makefile.PL) autom