Relax release constraints for #7004 #7084
Conversation
Mainly because the dev bundle is so big, it took upwards on 5 mins (on my MBP w/ SSD) to copy the warehouse packages into the sandbox. AFAICT there is no reason not to symlink it if we can.
For #7004. Still working on the self test but it appears to work :)
tmeasday
changed the title
|
I've read over the code and everything makes sense to me. I'd like to play with it a bit more just to make sure the workflow for updating packages is smooth, but I don't have an objection to merging this to |
|
Oh, I think maybe we should merge it to We should probably do a proper beta release with it in it so we can test the code for real before merging to devel |
|
Oh and I expect the tests to pass, I'm rerunning them |
|
Yes, I've concluded this is a real failure too. In fact I'm no longer sure
|
The issue was the order of the two matches kept changing due to ..?.. (various factors I guess).
|
@benjamn If you are happy with this, let's merge it to |
|
Merged to |
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.
Ready for review @benjamn