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:
Backwards compatibility
Modules which are "stable" should not break backwards compatibility without at least a long transition phase and a major change in version number.
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:
use Some::Module::alpha; # supported as is use Some::Module::alpha::warn; # as is, opt-in to future warnings use Some::Module; # may evolve without warning
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?In reply to Planning for Backwards Compatibility by bsb
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |