I was browsing through the solr-ruby project svn directory when i can across CHANGES.yml (sample below):
- v0.0.5
release_date: 2007-08-??
changes:
- Added support for highlighter fragment size to Solr::Request::Standard
- Added support for MoreLikeThese to Solr::Request::Standard
- Added Solr::Request::ModifyDocument (requires SOLR-139 patch)
- Added Solr::Util.query_parser_escape()
- v0.0.4
release_date: 2007-08-16
changes:
- Solr::Indexer#solr added to gain access to the Solr::Connection instance
- Fixed issue with multi-line String field values when field set multiValued="false"
- Fixed tests to work without either Hpricot or libxml2
This makes total sense -- Machine parsable high-level changelogs. I'd love to see a spec created for this. A quick poll of #perl-qa show that some other folks agree. I searched around but couldn't find any existing specs -- any takers? :)
should be ended with ':'. But I think this idea only flies for real simple Changelogs. In CPAN, you find a great diversity of different markup people use for distinct things: bug fixes, new feature implementation, doc patches, etc., etc. That's not easy to be captured in a simple format. And if it is not simple, it will scare people away.- v0.0.4:
Re:Bad YAML
Alias on 2007-09-06T02:48:04
It would be nice to have A optional standard to use though, even if it isn't enforced or even expected.
I've been meaning to write a Changes file parser/modifier for a while, so I can do automated incremental module releases for some modules.
This would make it damned easy.
Re:Bad YAML
Alias on 2007-09-06T07:32:10
AN optional standard would be nice too.
Re:Not YAML
kwilliams on 2007-09-06T12:08:14
What are the alternatives?Re:Not YAML
rjray on 2007-09-06T23:16:29
XML. Which raises cries and lamentations of its own, of course. See my longer reply, below.Re:Not YAML
stu42j on 2007-09-06T14:54:35
I like YAML but I do wish that it was more widely available. I'm afraid that making it so flexible has made it too difficult to write compliant parsers. One of the things I like about the basic YAML syntax is its simplicity; is it really useful that you can write YAML that looks like Javascript?Re:Not YAML
shngn on 2007-09-06T23:44:39
Why is it a failed format? Could you provide a reference for that statment?
This is a very good idea, but mostly because a standardised changelog format gives us options like automatic pre-release checks of the file ("Have I updated the Changes.yml file before uploading the package to CPAN?") or making new Kwalitee tests for CPAN-friendly packages.
Oh, and the syntax can be "fixed" by adding a ":" after the version number (see v0.0.1 in the example).
- v0.0.1:
release_date: 2007-02-15
changes:
- initial release
Re:Good idea!
sjn on 2007-09-06T15:17:38
Hmf. Should have properly read the other comments first.
:-P Anyhow, I think that format doesn't look too bad, and I definitely think it may be worth promoting.
:) Here comes spec v0.01...
RGiersig on 2007-09-07T09:25:21
No, fix it right:Oh, and the syntax can be "fixed" by adding a ":" after the version number (see v0.0.1 in the example).
- version: v0.0.1
release_date: 2007-02-15
changes:
- initial release
And Viola! We have v0.01 of our spec!:-)
I like YAML for its readability due to its lack of sigils (unlike JSON). And for simple YAML there is YAML::Tiny which can handle those basic structures, namely a list of hashes., just fine...
I've been using a home-brewed XML format for some of my changelogs. I also (of course) keep a more traditional-format CL in the distro. I've been working on some XSLT stylesheets and an article about it for XML.com, but lack of tuits has slowed me. This may be the nudge I need to finish it.
Of course, mentioning XML alone may raise cries from those who are tired of seeing it applied to every vaguely-text-data-related problem that comes along. And I understand (and sometimes share) the sentiment. But in this case, I've developed a spec over time that encompasses things like I18N (to a certain degree), allowance for plugging in "modules" to specify source-control information, etc.
This isn't to say I think it's perfect, or even complete at this stage. The kernel of the idea came from ruminating on how hard it would be to completely automate the build+release process, from "perl Makefile.PL" all the way through updating my personal web pages and creating a Freshmeat.net announcement. The thought of being able to easily ("easily" being a relative term, of course) generate a plain-text ChangeLog, an HTML-ified prettier ChangeLog.html, while also extracting the specific changes for the given build to include in release announcements, etc., is very attractive.
Like I said, maybe this is the ass-kick I need to finish the XSLT and at least write a simple overview, if not an article...
Re:XML, the Anti-YAML
Alias on 2007-09-07T01:03:01
If you don't need a Schema, you don't need XML...Re:XML, the Anti-YAML
hex on 2007-11-08T12:28:14
miyagawa has drawn my attention to Net::Flickr::Backup, whose author uses the estimable DOAP RDF vocabulary in his Changes files. Aaron appears to have extended it in his own fashion, which with a little work could be a very promising format for this sort of thing.I'd be very interested to see that overview/article, and perhaps contribute to the effort.
