use Perl

• What I'd want (Score:1)

  by Skud (28)

  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

  --
  Kirrily "Skud" Robert perl@infotrope.net http://infotrope.net/
  • Re: (Score:1)

    by RGiersig (3217)

    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.
    • Re:What I'd want (Score:1)

      by sjn (3626) <reversethis-{gro.vvp} {ta} {lrepesu+njs}> on 2007.09.07 10:52 (#57596) Journal

      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 making it easy to write a Changes.yml file - if people are "forced" to write a lot of redundant information in order to make a "good" or "valid" Changes.yml file, then they may conclude that this may not be worth the effort. In other words, there may be some worth in considering what fields "MUST", "SHOULD" or "MAY" be required. :)

      Other than that - good stuff! Keep up the good work! :)

      Reply to This

      Parent

      • Re: (Score:1)

        by RGiersig (3217)

        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