This included removing some internal version constraints. It would be
nice if package A could say "use B@2.0.0" (when both have changed), but
when they're both in the release, we need to make a release that has a
B@2.0.0-rc in it, which doesn't match that constraint. Fortunately,
constraints aren't necessary within a release anyway.
Fill in all packages without README.md files with a short
README.md mentioning that this is an internal Meteor package.
Break up the top paragraph of a couple of existing README.md
files to be proper long description.
There is more work to do here, involving line wrapping and the like.
It seems like a good practice for tests to always be grouped under their package name, so that it’s easy to find the tests when they fail. It’s confusing to have the tests in packages like “spacebars-tests”, “spacebars-compiler”, and “templating” be in various groups like “spacebars - templates” and “spacebars - templating”.
I didn’t go through and enforce this convention in all packages, just a few, but I think it would be good and not too hard to do the rest sometime.
