On 2011.3.3 5:56 PM, (Andreas J. Koenig) via RT wrote:
Show quoted text> Just because I noticed the huge number of subtest cases:
> 63326, 63376, 63863, github 96. 114. 128. 129. 130. 136.
>
> If so many cases come out of the dev releases that seems like a natural
> selection for "Prio A" (as we call it at $work).
Yeah, I can see how it might look like they're piling up. But I see it as
just one broken feature.
It's not priority A several reasons but primarily because it's a relatively
rarely used, well-encapsulated feature that I can ignore while developing
other things. subtests can be busted without affecting anything else. And
they're not a cool new TB2 thing that's going to attract developers to use and
work on TB2. And I'm pretty sure how to deal with them.
The alpha releases are to gather data about what's broken, but not so much to
make distributions work. That'll happen in release candidates. I might fix
stuff if it's easy, but subtests will be a bunch of work that isn't really
going to benefit anything else. And there's a lot to do.
It is on the list of major features.
* Convert Test::More
* Structured diagnostics
* Threads
* subtests
* Test::Warn/Test::Exception nested tests
* Making it easier to use TB2 directly
* Test::Builder2::Tester
I've been keeping a list of blockers
https://github.com/schwern/test-more/issues/labels/Blocking%20Stable
--
We do what we must because we can.
For the good of all of us,
Except the ones who are dead.
-- Jonathan Coulton, "Still Alive"
RT for rt.cpan.org