.meteor/packages version constraints for core packages



When I upgraded to 1.4.1 from I noticed package versions have been added for all core packages present in .meteor/packages. I understand this is related to unpinning those package versions from meteor releases. Are these the recommended core package versions for 1.4.1 and then when I upgrade to a later version of meteor these versions will be incremented by meteor update? … until you’re ready to completely unpin … left a bit confused here.



You won’t generally get any automatic updates. You’ll need to meteor update package1 package2 ... (or meteor update --all-packages.

# Meteor
mongo@1.1.12                   # The database Meteor supports right now
# Meteor 1.4.1
mongo@1.1.11                   # The database Meteor supports right now

The above is the specific behavior I’m curious about. Running meteor update caused my .meteor/packages version constraints to be updated. In the past I’d expect only .meteor/versions to be updated by meteor update with the caveat that .meteor/packages might occasionally be updated by a .finished-upgraders.

@benjamn @tmeasday perhaps you can shed some light on this behavior? I understand it has to do with the move toward core package version unpinning but haven’t been able to find a good explanation of the new way in which version constraints are being used on core .meteor/packages.


A package specification of the for mongo@1.1.12 is like a “less than or equals to”, so it’s not pinning the package version but instead “underpinning” if you like. You can still take future updates to mongo (or even alter that constraint to be different yourself) without needing to update your entire release.

Previously there was a implicit system where all your core packages were completely specified (and “pinned”) by the release.

Now we underpin the core packages that you have in .meteor/packages and ratchet it up when you do an release update (this is basically what a release update is now). For core packages outside of .meteor/packages (aka “indirect” core packages), things are a bit looser, thus the need for meteor update --all-packages.

If you are interested in the gory details, you could start reading here (and follow links): https://github.com/meteor/meteor/issues/7671


@tmeasday where is the code that ratchets up the package.js core package versions when you do a release update?

Thanks in advance. I’m afraid to admit I’ve having a bit of trouble locating it and I’m curious!


@mjgallag here I think: https://github.com/meteor/meteor/blob/devel/tools/project-context.js#L1015