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
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Maybe we should take a step back... (Score:1)
Come to think of, the process is in two steps:
With each release, a new specification is created. After the release, the original specification is retroactively changed by reported but previously unknown "features" that we normally call "bugs". During bug-fixing, these "features" are removed and the change is documented in the specification of the next release.
I don't know what I will make of all this, it's rather late and I'm going to bed now.
Does this make any sense for you others that are not me?
Reply to This
Re: (Score:1)
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 so
Re: (Score:1)
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