My first instinct is to do something like this:
This would mean that if a 3rd party dev wanted to support v1 then would make sure to do the MyAPI::Version::One role, and if they wanted to make the commitment to always stay on the bleeding edge they could do the MyAPI::Latest role.package MyAPI::Version::One; use Moose::Role; require 'foo'; require 'bar'; package MyAPI::Latest; use Moose::Role; with 'MyAPI::Version::One';
Then when you update to a new version you simply do this:
And then all 3rd party devs who were doing the MyAPI::Latest would have to be sure to update but those who did the MyAPI::Version::One role would still be safe and could upgrade to MyAPI::Version::Two when they are able to.package MyAPI::Version::Two; use Moose::Role; with 'MyAPI::Version::One'; # assuming back-compat require 'baz'; package MyAPI::Latest; use Moose::Role; with 'MyAPI::Version::Two';
This should still be workable when you break back-compat too since there is no strict requirement that the MyAPI::Version::Two does the MyAPI::Version::One role.
In reply to Re: Evolving roles and 3rd party modules
by stvn
in thread Evolving roles and 3rd party modules
by dgaramond2
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |