|P is for Practical|
Planning for Backwards Compatibilityby bsb (Priest)
|on Aug 20, 2007 at 01:24 UTC||Need Help??|
While reading for the Nth time "The interface could be better but we're stuck with it now", I began thinking about ways to provide better backwards and forward compatibility. I have some ideas but nothing ground-breaking and I'd like to know about any other techniques out there.
A few approaches to changes in API or Interfaces are:
If you plan to evolve an API or want to release a non-binding alpha version, you could provide an alternate name that you document as stable, while the main-line can change. For example:
Initially, "alpha" would basically be an proxy for the main module. Later it might be a backward-compatibility wrapper for the new interface. If the backward compatibility becomes impractical or restrictive then the alpha interface could become it's own package. The ::warn name extension (or "compat_warn => 1") could be used to opt-in to future compatibility change warnings.
I'm just brain-storming here and am interested in what others think.What have other people tried?
What works and, importantly, what doesn't?
Are there already PM nodes addressing this?
How does Perl 6's module versioning system address these issues?
(The naming of v6-alpha inspired me in part)