On Wed, Jan 28, 2004 at 11:52:45AM +0000, Adrian Howard wrote:
> >This should be less error prone and easier to maintain.
> [snip]
> 
> Hmmm... I'm not so sure that that's always (or even mostly) true.

At the moment the information must be maintained separately by each module's
user (if they can be bothered). Perhaps the amount of work required from the
module author increases, but the overall amount of work (much of which was
redundant) decreases. The only authors who will have to do lots of work are
those who break their interfaces every couple of weeks.

> -     I've certainly been caught by many accidentally introduced bugs / 
> subtle interface changes that the module author wasn't aware of (so no 
> interface change)

That would catch you with the old version system too. No version system can
stop the author from messing up. However with something like Version::Split,
authors could be notified whenever their new version claims to be compatible
with the old one but breaks other modules on CPAN. The reason that's not
practical now is that we have no way of saying "not compatible with previous
versions".

In this scenario the rest of CPAN becomes part of your test suite - the bits
of it that use your module anyway.

I can see an issue here though, there should be a way to exclude known bad
releases that claim to be compatible. A responsible author would remove such
a module from CPAN as soon as possible (they could upload it again in as new
release that doesn't claim to be compatible).

> -     I've also carried on using modules that have had interface changes 
> without problems - because I've not been using that particular piece of 
> the API.

Yes, this has been brought up. In some cases you could blame the author for
not making the module fine grained enough but that won't solve the problem.
A more practical solution is to require version A or version B . Yes this
goes back to forcing the user to specify information that should be provided
by the author. However it should hopefully be unnecessary in most cases.
When it is necessary, the information is limited to a (hopefully) short list
of acceptable versions. Finally, the information would only need to be
updated whenever a new version comes out that is declared to be incompatible
with older versions but is actually good enough for your use. This should be
quite rare.

I'm not saying Version::Split solves everything but if it can move 99% of
the version work to the module author and still let the user do the final 1%
of fine tuning then it's an improvement,

F

Reply via email to