On 12 Mar 2007, at 12:15, Fergal Daly wrote:
Highest version I'd say. I hope we're not expecting such a complex
melange of versions that we need to enumerate the ones we support. If
say we're supporting version 10 it's implicit that we also support
1-9.
Are we not anticipate any bad decisions either? Say version 8 was
horribly broken and no one should ever support it. By saying you don't
support it the producer should then fall back gracefully to something
earlier.
If 8 is horribly broken why's the producer trying to produce it in
the first place? How likely is it that we're going to allow a
'horribly broken' TAP grammer into the wild?
What about the future? Maybe it's 20 years later and I'm writng a TAP
parser in C#++ and I don't want to have to cater for every version of
TAP that's ever existed, including the broken ones. So I say
"12,90-100" the producer can either produce up to date TAP or fall
back to the very basics.
Madness :)
I don't want every producer written from here forward to have to be
able to negotiate its way through a minefield of supported versions.
From the producer's point of view the logic should be as simple as
checking that the harness supports our version. If it doesn't emit a
diagnostic and skip.
If you insist on full backwards compatibility all the way back to the
start then you future TAP consumers are just going to lie. They'll say
"100" which is supposed to mean "1-100" but they're just going to hope
that nothing earlier than 90 ever shows up. If you're lucky they'll
die when they see a version number they don't support but by
communicating the reality the user could get the best available.
Plus saying "1-100" is only a tiny bit more difficult than saying
"100"
It transfers a lot of burden to the producer though. It means that
every producer from now on has parse a discontinuous selection of
version numbers and then do the right thing. The negotiation stage
ends up being more onerous than the actual testing.
--
Andy Armstrong, hexten.net
