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.

Changes.yml specs v0.01 4 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • I've been doing CPAN Watch [perlbuzz.com] for a couple of weeks now and I'm starting to get a handle on what I'd want if I had a machine-parsable changelog. A few random notes:

    To me, the main distinction in changelogs is "noteworthy" and "not noteworthy". Bugfixes, additional features, and breaking backwards compatibility are noteworthy. Things like packaging fixes, test improvements, etc are not noteworthy. Admittedly my criteria are very personal here, but I think the distinction of "you might want to upgrade on account of this" vs "mostly of use to the maintainer" is worth noting.

    A week or so back I came across some kind of XML format for changelogs. I have no recollection as to what it was, just that I hated it for its non-human-readability. You might want to investigate and see what it includes.

    Random things that you might want to be able to capture in your YAML format:

    • change of license
    • change of maintainer
    • flag for "major release!!!!1"
    • packaging changes (is license change a subset of this?)
    • test changes
    • documentation changes
    • bugfixes
    • features added *or* removed
    • changes in maturity, eg "I now consider this to be out of alpha, and ready for use by others" or "this is a release candidate"
    • developer releases?

    And please, make the YAML format be in reverse chronological order. This is much better for human readability because hte most recent changes are most readily apparent.

    --
    Kirrily "Skud" Robert perl@infotrope.net http://infotrope.net/
    • Hmm, cpan watch would really be a major user of this, so I'll keep that in mind. So I guess making too many things in Changes.yml optional is bad, either an author should include all infos or just leave out Changes.yml alltogether.

      So the release info should contain human-readable info on the one hand like a one-sentence synopsis for cpan-watch and parseable info on the other hand like API-changes, changes in dependencies etc that allows some nifty tools to combine that with info from other packages to e.g.

      • META.yml is rather established, and quite useful for determining the current state of a package. I don't think it's productive to speculating in merging files or making one replace the other.

        Instead, I suggest that Changes.yml ONLY contains information regarding the changes between releases (as opposed to info regarding about the release itself, which is available in META.yml). That would mean fields like "author" should be redundant/meaningless in Changes.yml.

        Furthermore, there's much to be won by maki

        • Right, I don't intend to merge files, and be it just for backward-compatibility.

          With "author" I meant the author of that specific release, not necessarily of the whole module. I don't know if "pumpking" would be better, as I see that title as a honor to those that coordinate releases on really large module/packages/whatever. Maybe "brought-to-you-by" would be better... No, let that be "release-author". :-)

          [Which brings me to the point if there shouldn't be a list of bug/patch contributors that could be auto
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.