[proposal] Set module major version to TAP protocol version
Closed this issue · 4 comments
To developers:
tap-parser: @substack @isaacs
karma-tap: @tmcw @bySabi
karma-tap-reporter karma-tape-reporter: @fumiakiy @terinjokes
Hi all!
I was trying to improve the work of @tmcw on 'karma framework adapter' karma-tap. Karma adapter are not aware of framework version. We cannot pass protocol version from tap parser through karma tap adapter up to karma tap reportes. Packages like karma-tape-reporter hardcode protocol version.
This proposal is to enforce TAP protocol version with modules major version, say:
- tap-parser from
1.2.2to13.x.x - karma-tap from
1.0.4to13.x.x - ...
I don´t see this like a la karma fix, and more relate to TAP modules ecosystem.
any discussion is welcome.
I don't think we should do this.
Modules need to be able to increment their own major version independently of their dependencies. For example, if tap-parser decides to change its API, it would need to increment its major semver. It might need to do this many times. That must be independent of TAP's semver.
It seems the root problem you're trying to solve is that it's impossible to tell programmatically what TAP version a particular library promises to use. Am I right?
Yes, I cannot pass TAP version from parser upto final destination, karma-tap-reporter.
You are probably right @anko and parser must stay on current semver but for packages with not subtle to change API´s like karma-tap, karma-tap-reporter, karma-tape-reporter could be fine.
Yeah, this isn't the first time this idea has been floated. It's an intuitively appealing idea which seems to make a sort of sense at first, but we're not gonna do this.
The version of the parser is not entirely dependent on the version of the protocol that it parses. That's just one factor. A parser takes as input the protocol, provides some programmatic interface, and has a consumable logical structure as its output. If the logical structure or programmatic interface change, then the major version has to be updated, so taking on a versioning scheme like this would be misleading and restrictive.