Release 1.4.2.5 #8311
Release 1.4.2.5 #8311
Conversation
…ules." This reverts commit 6c643a4.
`modules-runtime@0.7.8` was already released but this part of the commit was included in a larger commit which was reverted. This simply puts the version in-line with the `devel` branch.
abernix
force-pushed
the
release-1.4.2.5
branch
from
2c99a93
to
7fc3627
Compare
| @@ -13,10 +13,6 @@ if (typeof Profile === "function" && | |||
| }; | |||
| } | |||
|
|
|||
| // On the client, make package resolution prefer the "browser" field of | |||
| // package.json files to the "main" field. | |||
| options.browser = Meteor.isClient; | |||
There was a problem hiding this comment.
@abernix Let's not revert this change?
There was a problem hiding this comment.
@benjamn Yes, it shouldn't be reverted and the commit above is actually deceiving as I didn't end up publishing modules-runtime in the release process for rc.0. But this should accurately reflect what was published. I'll fix this.
This code was reverted in 32140c8 as part of a larger revert, but this particular change should actually remain since it is how modules-runtime@0.7.8 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.
|
Hm, why I am getting that |
|
@mitar You can find the Obviously, we still need to figure out what exactly that means for the |
|
Yes, it is merged now, because this pull request got merged into BTW, one cool thing could be to display the segment of history.md file in the console. So one could see there what is new. Instead of having to go to the GitHub. |
Package version unpinning (#7084) removed all exact package@=version constraints derived from the current release. As we discovered with Meteor 1.4.2.4 (#8306), this meant releases no longer had any power to enforce package upgrades, which is why the follow-up Meteor 1.4.2.5 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.
During the final stages of the release process for Meteor 1.4.2.4 (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
meteor update --all-packagesormeteor update modules-runtime. This is because Meteor 1.4.2.4 requiresmodules-runtime@0.7.8and its dependency on (NPM)install@0.8.4to function correctly. See this commit oninstallor #8213 if you're interested in the logic behind that (important!) change.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 1.4.2.4 was not (and will not be) marked as
recommended(i.e. made official).In an ideal world
meteor-toolcould have forced a minimum version for this Atmosphere package to0.7.8but due to version unpinning this update would not have been enforced by theconstraint-solver. This will likely be addressed in the future.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.