Tighter version constraints on exported packages

[nex3]

Per the new exported dependency guidelines, the dependency constraints for di should be narrowed to >=3.3.2 <3.3.3 and route_hierarchical to >=0.6.1 <0.6.2.

[naomiblack]

This seems nice to have, but we also need to add some automation to the CI tests to check against new versions.

[rkirov]

Closing this issue, because Chirayu and I had a chat about this issue and we are not 100% convinced in the need of tight constraints on exported packages. If a client wants to enforce a specific version of 'di' to be used they can add their own constraint on di.

[nex3]

I urge you to reconsider. By exporting a package, you're exposing that package's API as your own. To follow semantic versioning, you must have changes in your API—which now include changes in di's and route_hierarchical's APIs as well—reflected in your version number, and you can't do so without tightening your constraints.

Users expect these constraints. In practice they don't constrain the versions of exported dependencies, which means that as soon as they use an API from those dependencies they're at risk for breakage. For example, of the fifteen packages I surveyed on pub.dartlang.org that use angular, only one of them also has a constraint on di, and none have a constraint on route_hierarchical.