Test::More - New Maintainer, Also stop version checking!
This post is to announce two things:
1) I am the new maintainer for Test::More. Schwern and I got together this morning to move it to a github organization, Test-More, at https://github.com/orgs/Test-More/. We are working on getting the repository into a decent state. You will need to update your links, repo remotes, etc. https://github.com/Test-More/test-more/
2) Test::More 1.5 is suspended indefinitely. Regular Test::More will eventually reach the point where it will hit version 1.5.0, at this point the version will collide with the 1.5 experiment. There is probably *A LOT* of code out there that does version checking to see if it is running the 1.5 experimental code. This needs to be changed to check for capabilities instead using can(), for example Test::Builder->can("history"). Altering a programs behavior based on Test::More version is not appropriate.
We have split the repo into Test::More and Test::Builder2. We are working on moving all issues for Test::Builder2 and Test::More1.5 into the correct repo. That repo is https://github.com/Test-More/TB2
After things settle I will create a new blog post with a plan for future work on the Test::More/Test::Builder/Test::Simple ecosystem.
I blog about Perl.
This is awesome to hear. Organisations are an excellent tool and it's nice to see there being more and more of the Catalyst/DBIx::Class/Moose model of open discussion online and on IRC with multiple committers and shared ownership, and to give those of us who popularised it a chance to use the same techniques to improve parts of the stack we've long relied on but found high-friction to contribute to.
To people wondering why not re-use an existing org, there's a limit beyond which github's UI starts to get really aggravating to browse the repositories and given the harness layer is its own org, Perl-Toolchain-Gang is its own org, Catalyst, DBIx-Class and Moose all have their own orgs ... all I can really say is 'more is good'. Plus it'll be a nice change for me to have somewhere I'm *not* responsible for giving out commit bits :D
It seems much worse to release two different things named Test::More 1.5. It's counter to the whole purpose of versioning. I would even say it's completely appropriate to alter behavior based on version.
Nathan,
I agree that in 99% of cases it is fine to alter behavior based on version.
There was never an official Test::More 1.5 release. There were experimental alphas only. Some people helped Schwern by downloading these alphas, or using them on their cpan-testers machines.
Some people picked this up and started writing code that did things differently for versions greater than or equal to 1.5. This version specific code depends on the internals changed for 1.5, internals that have been put on hold, possibly forever. So 1.5 the experiment is done, and for now at least a failure (maybe too harsh a word?).
This leaves us in the bad situation of having modules on cpan that will break when Test::More inevitably bumps version numbers to 1.5+. Skipping 1.5 won't help because these modules look for 1.5+.
Nobody disputes that this is a bad situation. And you are free to argue that it should not have happened. But hindsight is 20/20.
Facts:
* Test::More will eventually hit 1.5 via maintenance
* Some modules expect 1.5 to have new internals
* The new internals are not happening in the near future.
Schwern and I both agree that fixing the modules that used alpha 1.5 is the correct thing to do going forward.
-Chad
I was concerned only with the specific line I quoted as it seems to be putting blame on the wrong place. However, with the clarifications you have made it seems like the sentiment of it was more along the lines of "assuming that features in an alpha release would be present in the final release is not appropriate".
Can’t wait to read what the new roadmap is.