use Text::Balanced qw(extract_multiple extract_codeblock), 1.95;
this could (under new semantics) assert only that those two functions have the same interface and expected behavior as the corresponding functions in module version 1.95. If a future version of Text::Balanced (e.g. 1.96) adds or changes the interface/behavior of other functions, my code will still accept the new module. Only when extract_multiple or extract_codeblock themselves change interface/behavior would my code reject a new module version. There is no need for my code to provide an acceptable version range; that is the module's responsibility to deduce. (OO-like modules must be handled by a different mechanism.)
Version every function!? This may seem like a lot of administrative overhead. However, we could permit some first-order logic in the definition of version metadata to make it concise. In words,
All functions in Text::Balanced 1.96 are compatible with those in 1.95 except
for extract_pod (a new hypothetical function) and extract_delimited
(presumably having a new interface).Notice that the version numbers on individual functions are not even specified explicitly. External conciseness makes the implementation complicated, but this Perl, which is supposed to be easy for humans at the expense of implementation complexity. The next step is to make the above statement more machine readable.
Versioning might not always fall cleanly on function/method boundaries, so we could also allow versioning on module tags:
use Text::Balanced qw(:extractors), 1.95;
A module might even provide two versions of a function. Like function overriding, the version used will depend on the version requested or, lacking that, be the newest version.
Consider further that another author comes out with a module named Text::Balanced::Python having the same interface as Text::Balanced 1.95 but whose extract_quotelike extracts Pythonic quotes rather than Perl-like quotes (i.e. differing behavior). I haven't considered how useful it would be to express this relationship in the versioning metadata, but that might be a further direction. This resembles (OO) interfaces, but I believe the versioning considerations make it different.
-davidm
Fergal Daly wrote:
> This is caused by trying to cram 2 version numbers into a single version > string with no separator. Our tools cannot tell where the interface version > ends and the bugfix revision version begins. > > What is the purpose of the version number? Given 2 versions of the same > module, my automated tools (like CPAN etc) and I should be able to > > 1. see easily whether each module is compatible with my software > > 2. know which one is "better" where "better" usually means later stable > revision but if I want it could take devel version into account etc. > ... > If we want to get really fancy, in the meta information for Module::Ken > 2.3.4_xx we could declare that this is in fact compatible with 2.3.2 (maybe > we decided that the interface change in the 2.3.3 series was a mistake and > have abandonned that branch). Now Module::Fergal, which thinks it wants the > latest 2.3.2_xx, knows it can happily use 2.3.4_xx, which means Fergal > doesn't have to update his Makefile.PL every time Ken releases a new version > and Ken doesn't have to keep backporting bug fixes to 2.3.2. to keep Fergal > happy.
