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.
  • Thniking about everything I come to a wider viewpoint: the Changelog is actually a diff between two module feature descriptions. So how about doing exactly that: lets create a formalized feature description for each version. This description needs only be quite basic, because we only want the diffs. So the first release is described by its documentation and following releases are adding and changing its features.

    Come to think of, the process is in two steps:

    With each release, a new specification is created.
    • Interesting idea, but perhaps it's better not to over-engineer this early? :)

      I think it would be better to define a minimal spec that's easy to implement, and possible to extend when it's useful to do that. And of course, it should be human-readable/scannable firstly (as that's the role of the Changes files today). Using valid YAML ought to fix the "machine-parsable" requirement nicely.

      YAML.pm seems to have tried to do something in that direction too, btw. Maybe worth taking a look/having a chat with some of the guys behind that module?

      • Well, I see adaption of such a thing mainly as a psychological problem, not a technical one. So I want to get the technique right, and this means to decide what semantics we want here. But you are right, lets keep it small and simple. :-)

        Yes, the YAML changelog is valid YAML. Apart from that, they started out to put each change as one stream entry, thus generating multiple entries with the same version instead of having one entry per version and the changes as a list. Well, that's a mistake that I wont make