new t/zzz-moose-outdated.t test
make room after package declaration for $VERSION, now being inserted by latest [PkgVersion]
more fixes to Moose::Manual::Exceptions::Manifest

now that the file is known to dzil in the early phases, we don't need to call
into SurgicalPodWeaver ourselves, but by the time it munges this file, we
haven't yet added our content -- so we need to insert that later, using a
bit of placeholder pod as a guide.
old Moose breaks with new Module::Runtime - must upgrade before running dzil
MooseX::HasDefaults dies on load, and its other modules have no versions - best to remove!
No need to load Moose::Deprecated twice in Moose::Util::TypeConstraints
as seen on #toolchain today (thanks rjbs)
punct
explicitly document that the "authority" API is not recommended to be used.

From a discussion at the QA Hackathon in Lyon.  While $AUTHORITY is exposed as
an API in Class::MOP and it is not intended to be removed (in the near
future), its existence is questionable and its use is not recommended.
added Moose::Util::is_role (thanks trs for the suggestion!)
Mention the newly added Moose::Util::is_role() in Moose::Role

Moose::Role is a likely spot to look for such a function.  Noting the
metaclass involved may be useful for folks rolling their own is_role()
checks.
Merge pull request #61 from tsibley/mention-is_role

Mention the newly added Moose::Util::is_role() in Moose::Role
Roles aren't classes, but they are packages

ilmari++ for pointing this out.
Merge pull request #62 from tsibley/class-vs-package-semantics

Roles aren't classes, but they are packages
fix package name for these cookbook documents
remove package statements from .pod, but preserve "provides" metadata and recipe munging

perl -p -i -e's/s/use (strict|warnings);\n//mg; s/package (\S+);/# PODNAME: $1/m; BEGIN { undef $/ }' $(find lib -name \*pod)
remove unneeded lib includes
Fix x_breaks entries, and generate the test that checks them

Conveniently this also fixes this issue:

<@haarg> ether: for the zzz-moose-outdated test, i get a lot of failures like 'MooseX::App is version unknown, but must be greater than version 1.22'
<@haarg> because they are trying to load Moose from blib, but it doesn't have a VERSION
<@haarg> this is using the Makefile.PL, not dzil
<@haarg> not a huge issue, but it might be worth defining a $Moose::VERSION and $Class::MOP::VERSION in that test
< ether> hmm yeah, that test wouldn't work so well from the repo when using the placeholder Makefile.PL
< ether> it doesn't make much sense to run the test at that point; it can just be skipped
 * ether flags this for fixing tonight.
< ether> actually I don't think the placeholder Makefile.PL is working out so well right now in other places, too...
< ether> anything that uses a dependency that then does a Moose->VERSION check will also suffer the same fate
< ether> I recall upasana running into this with MooseX::WithOverloading code a while back
< ether> so yeah maybe we should just hack $VERSION to 9999
< ether> ..or something
<@haarg> it generally doesn't matter, since the tests shouldn't be loading things that depend on Moose
<@haarg> it was a problem when depending on MooseX::WithOverloading, but that only would have worked as a proof of concept anyway
<@haarg> so i think hacking the version of Moose and Class::MOP (maybe Moose::Role?) to 9999 for that one test might be reasonable
<@haarg> or just having it skip when run via the placeholder makefile
< ether> I'll play with both variants. skipping might be better since Moose::Conflicts is generated via dzil anyway, so we'd be running the one that's actually installed, or blow up if there is no version installed yet
bump version to 2.1205
make room after package statement for [PkgVersion] to add $VERSION