schwern
commented
14 years ago Yes, this is the plan. So far there haven't been enough legacy dependencies to bother, and there weren't any serious perl5i::1 users to need an independent distribution. It'll probably happen at the 2 -> 3 transition.
A dist name like perl5i-2-2.3.4 might look awkward, but it reads fine and follows convention for packaging a module called perl5i::2. Breaking convention will break more than it will fix. Most folks will just install it from the CPAN shell anyway with "install perl5i::2".
Coordinating patches been major releases will be interesting once we start maintaining older major releases. The normal merge mechanisms cannot be used because a change in perl5i/3.pm does not know it should patch onto perl5i/2.pm. One way to avoid this is instead of manually splitting code up into major versions, it would be done by a build script. Then all branches would write to perl5i/X.pm, patches can be merged, and a build script would turn perl5i/X.pm into perl5i/3.pm.
From a purely functional perspective, in my mind, having 3 major versions ( 0, 1 , 2 ) of the same library shipped all in the one dist is reasonably ok, but it has caveats.
Mostly, dependency weight bloat.
If somebody is only needing ::0 , then pulling all the deps that make ::2 work is surplus to requirements.
This is especially meaningful if perl5i starts depending on stuff like MooseX::Declare, which will make the dependency weight explode, and in some cases, result in people who only need ::0 having perl5i not installable due to the likely case that a test somewhere will fail.
The problem with this of course is that, you'll have possibly bizzare dist names like perl5i-0-1.2 , which will be a little confusing.
maybe something could be worked into something like perl5i-API0-1.2 or something more intelligent.