* Sawyer X <xsawy...@gmail.com> [2015-05-02 23:05]: > Effectively what happened/happens is that, while plugins are now able > to provide two different implementations without worrying about > backwards compatibility (we originally wanted it to be seamless but > turned out to be very hard), most plugins had a shared core. This was > odd to maintain. You either fork it or you put it in a common "::Core" > module, or you ship both in the same distribution.
I was going to suggest shipping both in the same distribution – in fact if the code is completely identical you could put them in one file and basically just alias one namespace to the other, which seems desirable as it reduces the maintenance burden to “essentially free” – but there is a problem with that: dependencies and testing. Essentially the only sane thing is to declare dependencies on both of the ecosystems. Then you can also run your tests against each of them. But this obviously sucks for users. Yet the alternatives are worse. One of them is you pick one ecosystem as the preferred one. That sucks for users on the other side. Or you do not declare dependencies on *either* of them – which sucks for everyone. Also, the tests for any ecosystem that is not declared as a dependency will have to skip. But the user might then install that ecosystem’s core later, and then your plugin magically is already installed in spite of its tests against that ecosystem never having run. (Conversely if the user has both ecosystems installed and the tests for one of them fail but the tests for the other do not, there is no way to install the plugin for just one ecosystem but not the other.) All of this insanity is avoided if there is one plugin for one ecosystem and another for the other. Then they can each declare their dependency on the right one, and their tests for it can be run unconditionally, and if they fail, the other ecosystem’s version of the plugin is unaffected. But shipping a ::Core plus a wrapper for each ecosystem means you have to ship (at least) 3 distributions, and every plugin comes in 2 parts. That’s pretty annoying. I think the right answer here is “Dist::Zilla plugin”: i.e. you maintain a single codebase, in a single repo – but at release time, the authoring tool of your choice bakes you two distinct distributions to upload. The code in the repo can then be two-faced, and `prove` ought to run both sets of tests. This makes it natural from the maintainer’s perspective. And if the versions of the plugin need to diverge, from the perspective of the CPAN index, that transition to separate codebases is invisible. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
