The goal here is that we can determine which versions of a dependency your package works with just by looking at the api.use declaration. If you don’t specify the version of a dependency inside your package.js but expect that version to be included, someone using your package might run into a problem when they try to manually add some different version.
Basically, for the constraint solver to correctly identify the versions of dependencies when multiple packages have the same dependency with different versions, you need to specify what version your package works with.
Why not just put "aldeed:email@example.com" if that is the version you want?
If I specify “aldeed:firstname.lastname@example.org” does it automatically update when new version avilable, like when ‘meteor update’ ?
I like your point:
I agree that package developer should specify what version his packages works with - only point I am trying to put forth is - “If I do not specify the version, assume that I want the latest version. and not the oldest version”.
The design choice that "package developers want the oldest version" when they do not specify the version while "meter add" users want the latest version" - is not justified enough.
Package developer should get the same benifit as end user developer
Any info on how this backward compatibility is determined? Some kind of markup inside package.js?
Because looks like “aldeed:tabular” when used from inside a package (through api.use()) is not automatically picking the latest version - and wondering which part of the code inside aldeed:tabular is prohibiting it. Also, would be useful while developing own packages to ensure they are backward compatible.
On a side note though, it would be ideal for api.use to have same version picking behavior as meteor add. Explicitly asking to run meteor update every time a new api.use line added inside package.js is not so dev-friendly (given that meteor add does not demand it).