During the final stages of the release process for Meteor 188.8.131.52 (a bug fix release, #8306) it was realized that it was going to be necessary for developers to take the additional, possibly mandatory, step of running
Despite the simple solution (stated above) and while this was explained very clearly in the release notes, it was deemed too complex for this point release due to the additional intervention necessary by the developer. Meteor 184.108.40.206 was not (and will not be) marked as
In an ideal world
This release will simply omit 2eab0b2 (and associated changes) although those will remain in the upcoming 1.4.3 (#8123) release with the addition of an "upgrader" designed to take care of this automatically with no additional steps required by the end-developer.
This code was reverted in 32140c8 as part of a larger revert, but this particular change should actually remain since it is how firstname.lastname@example.org was and is published. I had initially thought that this commit would also be rolled back (and result in a 0.7.9) but that did not yield the desired result.
@mitar You can find the
Obviously, we still need to figure out what exactly that means for the
Package version unpinning (#7084) removed all exact package@=version constraints derived from the current release. As we discovered with Meteor 220.127.116.11 (#8306), this meant releases no longer had any power to enforce package upgrades, which is why the follow-up Meteor 18.104.22.168 release (#8311) was necessary. This commit has the same effect as putting package@version in your .meteor/packages file for every local/core package that your app uses.