This is less efficient, as we don't actually need to compute it every time.
However, I think this is pretty small compared to the other work we're doing
(string splitting via regexp, string copies, etc).
This makes the code clearer and easier to understand, as all the code is in
one place. Also, it was distracting at the top of the file as it came before
the commit saying what was in the file.
.meteor/packages in new apps now contains "standard-app-packages", which implies
the standard set of packages like mongo-livedata. There is no special-casing in
initFromAppDir. This line has been added to all the examples, etc.
There's a new concept of "upgraders". "meteor run-upgrader app-packages" will
add standard-app-packages to the app, as well as all of the package in the app's
packages/ directory (an unrelated change since 0.6.4). This will be integrated
soon with "meteor update"; run-upgrader is essentially for testing.
project.add_package no longer adds packages that are already there.
This package was always included in apps, and even if it was possible to remove,
there wasn't a compelling story about when users would remove and replace
it. Plus, not all backwards-compatibility code could even live in it (eg, field
names of objects), so it was incomplete. It also introduced odd load order
constraints.
Instead, we introduce two conventions for backwards-compatibility code:
- Special comments of the form "// XXX COMPAT WITH 0.6.4"
- When feasible, put backwards-compatibility code in a file called
"deprecated.js" in the relevant package.
This is documented at:
https://github.com/meteor/meteor/wiki/Meteor-Style-Guide#deprecated-code-and-backwards-compatibility
Additionally, removed some symbols that existed for backwards compatibility with
Meteor 0.4.0 (changes made 10 months ago): Meteor.is_client, Meteor.is_server,
and (in a method) this.is_simulation.
