Closed queso closed 10 years ago
I could take a stab at the PR, I think this is the general area where I would need to modify the code?
https://github.com/oortcloud/meteorite/blob/master/lib/dependencies/package.js#L53-L63
Hey @queso - appreciate you looking at this, and I can see the pain point.
I don't think it's worth the effort of implementing this because:
Fair enough. Just lost 30-40 minutes trying to track down which package was calling a stale version of a package I had just updated and released to atmosphere... I finally found it, just took a while. Problem would have been avoided if the package with the dependency could just use the minor version instead of the patch version :)
+1 to this. Same as #218. @tmeasday, do you have a link to something (issue, blog post?) where they say they're going to do this in Meteor 1.0? Tried looking quickly just now and couldn't find anything.
Response re #218 from @gschmidt on this trello card, which is sorted high on the 1.0 roadmap https://trello.com/c/d2Hd1Jo1 — I don't see that card assigned to anyone at the moment, though.
I expect that after Meteor UI is shipped, this will shift to forefront...
For those of us building packages, I would love to see support for sematic versioning.
I.e. if I specific a version in my smart.json package file, I would love to peg it to a minor version instead of a specific patch version:
That would have the benefit of allowing my package to work with both iron-router 0.6.1 and 0.6.2 without me releasing a new version just because Iron Router did.
/cc @ryw @tmeasday