Here is what I want to do. I want to release a Test-Stream dist on cpan. It will say in its POD that it is still experimental, largely because of this debate right now. This release will not be tied to Test::Builder, Test::More, etc. There will be a limited compatibility module people can choose to use if they want to try to mix old ecosystem and new. This module will be considered ultra-experimental with a note that it might go away completely if we decide it is not worth the effort.
This experiment will run for a little while, I am talking 2-6 months. At one point we will make a decision on the future of Test-Stream and Test-Simple: * Decide we have stabilized it and are ok with having a forked ecosystem (with possible limited compatibility between them) * Decide that the forked ecosystem is a mistake and come back to the plan we have been using of having backcompat. * Decide Test-Stream is bullshit and abandon it. * Something else we decide based on information we do not have yet since the experiment has not happened There is no real reason not to release the separate dist now, specially if we warn people it is an experiment. We will also warn Test::* authors not to switch their modules wholesale to Test::Stream since they would then break backcompat. This is not outright an abandonment of the current plan. I will ensure that any work that occurs during the experiment is also merged into a 'punchlist' branch. If the experiment proves we do not like the forked ecosystem, and need to backtrack to this we can pick up right where we left off, and finish the punchlist (or come up with a new one). This is very much opt-in. Nobody will be required to use Test::Stream, or to maintain their tools in a compatible way. If it turns out nobody bothers, or they think the burden of supporting both is too much, we will know that this is the wrong option. If authors decide to try it, either by limiting their module to the backcompat api, or by supporting both, then we know that this alternative plan is a good one. *Ultimately* my personal motivation is this: The backcompat burden is huge, and has resulted in a lot of things I do not like in Test-Stream. I do not like carrying forward these bad things that are inherited. This option allows me to make Test-Stream much much better, and removes a lot of the burden. On Sat, May 2, 2015 at 12:36 PM, David Golden <[email protected]> wrote: > On Sat, May 2, 2015 at 3:03 PM, Stefan Seifert <[email protected]> > wrote: > >> What would that mean from a user perspective? Would one be able to mix >> Test::More and Test::More2 (and higher level modules based on them) in the >> same test file? >> > > No, I meant that a .t file would have to choose one or the other. So, for > example, if I had a Test::More2 .t file, I'd have to use Test::Fatal2, > Test::Deep2, etc. that are all built on Test::Builder2. > > Meanwhile, anyone would still be free to have a .t file with Test::More, > Test::Fatal, etc. > > There are only a handful of really commonly used Test::* libraries and I > suspect that they could be forked to use Test::Builder2 trivially, as few > of them wind up needing the interesting new bits. Only the Test::* modules > that were monkey patching or can take advantage of hooks would need any > real revision. > > David > > -- > David Golden <[email protected]> Twitter/IRC: @xdg >
