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
Module-Changes
More |
Login
| Reply
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
an endless discussion thread about what features to include.
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Format of Changes.yml (Score:1)
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 loo
Re:Format of Changes.yml (Score:1)
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) automated and hidden away.
Personally, I believe that putting too much "machine-only information" into Changes (for example the RDF-abomination) makes it impossible for me as a human to take a glance at the Changes file and see what changed. Putting too much structure into the YAML thing is about the same - I already dislike the --- stream delimiters where a simple newline does the same, but those stream delimiters are very close to the structural limit I'm willing to afford.
But maybe there is a need for a parser that parses the more conventional format(s) of Changes files, so if you can make your module have the appropriate hooks to guess the format of a Changes file and then call the appropriate parser plugin, that would be a convenient start. People who use your module can then support other formats by writing new parsers.
Reply to This
Parent
Re: (Score:1)
I'm stupid. I just saw Module::Changes::Parser::Free [cpan.org] , which does just what I proposed. Thank you for anticipating my complaints :))