Why upper bounds in Project.toml?

I have not clear the meaning of mandate an upper bound for dependent packages in Project.toml.

I normally require the functionality of a package, I know this functionality in package X has been added at version Y.Y.Y, so I require at least package X v.Y…Y.Y
But I normally have no idea which is the development plan of that package, e.g. if version v.Y,Y+1,Y or v.Y+1,Y,Y will still be good or break compatibility with my package…

Yes, that’s exactly why upper bounds are required. An upper bound means you declare compatibility only with some number of versions (so there is an upper bound on the version number you claim compatibility with), since it’s impossible to know that your package is compatible with all future versions of some dependency. The idea being it’s better to not necessarily get the latest version of a dependency if there is a chance it will break your code.

4 Likes