This way we don't get a stack overflow when materializing nested
Views. Certain browser/OS combinations seem to have particularly
low budgets (especially Firefox/Windows apparently).
Verified by running https://github.com/mxab/meteor-call-stack-exceed
on Chrome/Mac. Nesting limit used to be about 160, but now you get
unlimited nesting (tried up to 10,000, which renders in about 7-8
seconds).
Tested for correctness by running all package tests.
Note: we are doing a minor bump facebook rather than a major bump, even
though this is arguably backward-incompatible. But it's only reflecting
a backwards-incompatible change to reality, and we expect the upgrader
text to do a better job of expressing compatibility concerns than the
version number. There's no reason to make Atmosphere packages that
depend on facebook republish, as they are unlikely to need any changes
anyway (mostly, apps may).
Facebook is making a change on April 30th: all users of the previous
unversioned Facebook API will automatically start using the 2.0 API, and
the 1.0 API will be unavailable. By upgrading your Meteor to include
this commit, you will be able to start adapting your app to the post-1.0
world now rather than next month.
Full information about the changes to Facebook's APIs can be found at
https://developers.facebook.com/docs/apps/upgrading
If you only use Facebook integration for login via accounts-facebook,
and don't use users' access tokens to access the Facebook API on their
behalf, then the only changes you are likely to observe are:
- The `id` returned by Facebook for users who had not previously used
your app will be an "app-scoped ID". You cannot use these to directly
correlate users between multiple apps (without using the Business
Mapping API). This does not affect users who have already logged in
to your app, so they will continue to be able to access your app.
- Meteor asks for the `email` permission by default, and copies the
`email` field from the `/me` object into the `serviceData.facebook`
field on `Meteor.user()`, along with other fields which only require
the `public_profile` permission. With 2.0, users can decline to grant
all permissions other than `public_profile`, which means that you
might not get their `email` address. You can use the `/me/permissions`
API to tell if permissions were declined.
Additionally, if you are accessing other Facebook APIs using the
`access_token` returned via login, you should be aware that some
permissions have changed in Facebook Graph API 2.0 and newer. Most
notably, many operations involving friends need permissions such as
`user_friends` to be explicitly requested now. Users can decline any
permission (other than `public_profile`). Apps which need permissions
other than `public_profile`, `email`, and `user_friends` may need to
pass through a review stage before being fully activated.
To change your app to request new permissions such as `user_friends`,
specify the `requestPermissions` option to
`Meteor.loginWithFacebook` (if you implemented your own login UI) or to
`Accounts.ui.config` (if you are using the `accounts-ui` package).
Note that while Meteor will now always use the v2.2 API to fetch the
access token, it does appear that the access token can still be used to
access pre-v2.2 APIs. For example, you can still use the access token
to run FQL queries, even though FQL was removed in API v2.1.
Fixes#3123.
Facebook is making a change on April 30th: all users of the previous
unversioned Facebook API will automatically start using the 2.0 API, and
the 1.0 API will be unavailable. By upgrading your Meteor to include
this commit, you will be able to start adapting your app to the post-1.0
world now rather than next month.
Full information about the changes to Facebook's APIs can be found at
https://developers.facebook.com/docs/apps/upgrading
If you only use Facebook integration for login via accounts-facebook,
and don't use users' access tokens to access the Facebook API on their
behalf, then the only changes you are likely to observe are:
- The `id` returned by Facebook for users who had not previously used
your app will be an "app-scoped ID". You cannot use these to directly
correlate users between multiple apps (without using the Business
Mapping API). This does not affect users who have already logged in
to your app, so they will continue to be able to access your app.
- Meteor asks for the `email` permission by default, and copies the
`email` field from the `/me` object into the `serviceData.facebook`
field on `Meteor.user()`, along with other fields which only require
the `public_profile` permission. With 2.0, users can decline to grant
all permissions other than `public_profile`, which means that you
might not get their `email` address. You can use the `/me/permissions`
API to tell if permissions were declined.
Additionally, if you are accessing other Facebook APIs using the
`access_token` returned via login, you should be aware that some
permissions have changed in Facebook Graph API 2.0 and newer. Most
notably, many operations involving friends need permissions such as
`user_friends` to be explicitly requested now. Users can decline any
permission (other than `public_profile`). Apps which need permissions
other than `public_profile`, `email`, and `user_friends` may need to
pass through a review stage before being fully activated.
To change your app to request new permissions such as `user_friends`,
specify the `requestPermissions` option to
`Meteor.loginWithFacebook` (if you implemented your own login UI) or to
`Accounts.ui.config` (if you are using the `accounts-ui` package).
Note that while Meteor will now always use the v2.2 API to fetch the
access token, it does appear that the access token can still be used to
access pre-v2.2 APIs. For example, you can still use the access token
to run FQL queries, even though FQL was removed in API v2.1.
Fixes#3123.
The constraint-solver now uses the logic-solver in such a way that
accessing variables that weren't part of the problem statement will
never throw an error. That way, we don't have to worry about
present and future cases where we don't generate any logical formulas
involving a package "foo" and then we say to minimize some weighted
sum over packages including "foo".
Unloaded packages mentioned in weak dependencies could trigger a
situation where the logic solver is asked for the value of a variable
that doesn't exist. This issue is worth looking into in more detail,
but this is a strict improvement that addresses the basic case.
It used to create a directory with an underscore instead of a colon
Now, it just removes the prefix.
In cases where the name of the package has more than one colon or starts or ends
witha colon, we report an error.
Very useful for us or users to run! If there's a bug anywhere in the
constraint-solver or logic-solver package that comes up when using
the tool, we can probably reproduce it just by feeding the JSON that's
printed out into the constraint-solver in a test.
With this change, `meteor update` with no arguments, in addition to
updating direct dependencies, updates patch versions of indirect
dependencies, so you will get your version 1.4.2 in the above example.
Background: As of the new solver, we already prefer patched versions
when selecting a version for a new indirect dependency. For example,
if 1.4.0 is the oldest version we could choose, we will take 1.4.1
instead if available. However, if 1.4.2 came out, there would never
be an occasion to take it, unless you explicitly typed
`meteor update the-indirect-dependency`. `meteor update` with no
args expands to `meteor update <all direct deps>`.
Also improve comments, tests, and code around CS.Input.
Tracker.flush() will still guarantee that all computations and
afterFlush callbacks have been fully flushed, but the implicit flush
cycle started by an invalidation or afterFlush call will yield to the
event loop for 10ms every thousand computations.
Fixes#3901.
Reviewed at https://rbcommons.com/s/meteor/r/25/
In particular, ban leading `-`, trailing `.`, and `..` anywhere.
This backport commit drops the changes to constraint-solver and adds a
History.md note.
