Re: On Not Merging new and old behavior ( was Re: Test-Stream + MongoDB scalar refcount issue )

Test::Stream will still have a no non-core dep policy, so depending on both
Test-Stream and Test-Builder effectively adds 1 dep, that is not burdensome.

On Sat, May 2, 2015 at 3:34 PM, Aristotle Pagaltzis <[email protected]>
wrote:

> * Sawyer X <[email protected]> [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/>
>