The beta released with this commit (modules-beta.6) included everything on
the release-1.3 branch up to bdf64da339
("Avoid circular package.json resolution chains.").
Unfortunately, additional commits were pushed to the branch before this
commit was pushed, so the release tag release/METEOR@1.3-modules-beta.6
does not correspond to any commit in the branch history.
Rather than attempting to rewrite the branch history, I decided to amend
this commit with this explanation before pushing it.
To see exactly what was released with the sixth beta:
git fetch --tags
git log release/METEOR@1.3-modules-beta.6
Tried to get everything to an rc.0 of the very latest version,
which required some research in some cases about the published
versions. For example, some packages had version histories like:
```
...
1.0.3-winr.2 January 20th, 2015
1.0.3-winr.3 February 24th, 2015 installed
1.0.3 March 17th, 2015 installed
1.0.4-anubhav.0 August 6th, 2015
1.0.4-plugins.0 July 22nd, 2015
1.0.5-galaxy.0 July 17th, 2015
```
In this case, I would bump the version from `1.0.4-plugins.0`
to `1.0.5-rc.0`, skipping `1.0.4`.
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.
In the case when user or user:email scope wasn’t provided, use the
publicly visible email as before. In this case you can end up with not
having an email for GitHub accounts.
The email provided by the user info in the response from /user is the
publicly visible email, which a user can choose to not set.
GitHub accounts always have a primary email, so let’s use that one
instead.
These were broken by the Template.foo.bar -> Template.foo.helpers({ bar:
... }) transformation. `fields` is a property on the template object,
not a helper.
UIWebView which aren't able to use the preferred "popup" login flow.
See the specs for details:
https://meteor.hackpad.com/OAuth-redirect-flow-spec-PeziTcaNPDPhttps://meteor.hackpad.com/OAuth-redirect-flow-part-II-vswwUKP4vXe
I extracted code to construct a URL from the `http` package into a new
`url` utility package. The new package has no public API, it simply
has the original URL construction functions that were in `http` and
makes them available to oauth.
Fixes the Meetup account login, as Meetup now requires using
"https://api.meetup.com/2/members" instead of
"https://secure.meetup.com/2/members".
The `?close` parameter for the redirect URI is now not needed or used.
For backwards compatibility the `?close` parameter is included if the
login service configuration doesn't include the `loginStyle` field
(indicating it was created using old code).