--- Fergal Daly <[EMAIL PROTECTED]> wrote: > What you're saying is we can _never_ break backwards comatibility. > That is not the impression I got from previous discussions.
Sorry if I gave that impression. I don't mean 'never'. I mean we have to have a huge amount of bang for our buck to justify this. We also have to have some level of consensus on how to approach something like that. Breaking backwards compatibility is an option, but one which should be explored very, very carefully. > What I'm saying is, this break backwards compatibility but the > producer can fall back to plain ol TAP if it knows the consumer can't > handle it. I can easily envision scenarios where the producer would have no idea who the consumer is. I would also suggest that the producer should never know or care who the consumer is, though I can easily understand counter-arguments. > > There are several ways we could accomplish the same thing without > break > > backwards compatibility. Let's explore those. > > Show me one that actually does what I'm looking for, That could be tough, but I'm unconvinced that nothing else would work. Here's one which relies on the fact that the "ok/not ok" status must not have leading whitespace: 1..3 ok 1 2 1..2 # start a block 2.1 1..3 # start another block ok 2.1.1 ok 2.1.2 ok 2.1.3 ok 2.1 # inner block was all good ok 2.2 ok 2 # outer block was all good 3 1..3 ok 3.1 ok 3.2 not ok 3 # planned for 3 but only ran 2 tests Both 'prove' and 'runtests' parse this correctly. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
