Loosen dependency version requirements

[ericmj]

Hex packages should use non-strict dependency requirements such as ~> 1.0 instead of strict requirements like == 1.0.0. Strict requirements makes version resolution worse for users that use build tools that resolve versions like Mix/Hex.

[benoitc]

@ericmj The issue with it is that it breaks any support policy you can have. You can't ensure indeed that dependency will not break anything only based on their numbering what will happen if a user want to use an upper version ? Should we provide overlay when a support is sold?

[ericmj]

The issue with it is that it breaks any support policy you can have. You can't ensure indeed that dependency will not break anything only based on their numbering what will happen if a user want to use an upper version ?

If the dependencies you use follow semantic versioning the guarantee is that there are no breaking changes without a major version bump. Using the requirement ~> 1.2.3 will allow any version between 1.2.3 and the next major version 2.0.0.

Should we provide overlay when a support is sold?

What do you mean by "support is sold"?

[benoitc]

The issue with it is that it breaks any support policy you can have. You can't ensure indeed that dependency will not break anything only based on their numbering what will happen if a user want to use an upper version ?

If the dependencies you use follow semantic versioning the guarantee is that there are no breaking changes without a major version bump. Using the requirement ~> 1.2.3 will allow any version between 1.2.3 and the next major version 2.0.0.

As a general rule I prefer to block a version number for a stable release so I can support it. Semantic versioning isn't a label so it is still prone to error or instability when you don't control the dependency. It is also easier to rely on fixed release for automatic upgrades.

As for hackney, I can probably do it for the dependencies I have in control . But others will stay fix for a release. Those won't stay with the coming 2.x release though. Certifi is moving for another model of update so it will be handled apart.

Should we provide overlay when a support is sold?

What do you mean by "support is sold"?

well supporting a release of the code :)

[benoitc]

As for hackney, I can probably do it for the dependencies I have in control . But others will stay fix for a release. Those won't stay with the coming 2.x release though. Certifi is moving for another model of update so it will be handled apart.

meaning it will be possible to update your application witout stopping it when certificates are updated.

[ericmj]

As a general rule I prefer to block a version number for a stable release so I can support it. Semantic versioning isn't a label so it is still prone to error or instability when you don't control the dependency.

This is a tooling issue, lock files solves the issue of instability when new versions of dependencies are released. If there is an issue with a new dependency version then don't update it and let the lock file keep it at the same version.

It is also easier to rely on fixed release for automatic upgrades.

That's also a tooling issue, for example when mix/hex updates hackney with mix deps.update hackney it will also try to update all of hackney's dependencies.

It would be unfortunate if hackney and its dependencies decided to not follow semver when the majority of the general Hex ecosystem have adopted it from the start.

Not following semver gives less flexibility to users because hackney dictates what versions of other dependencies will be used. Say for example that a user depends on another HTTP client than hackney in their project that also depends on certifi, if both clients lock their certifi version it would be very hard to use or update both clients in the same project.

When creating the mint HTTP client we could not use certifi for this reason and had to create a new library castore instead because a project could not use both hackney and mint without versioning conflicts.

[benoitc]

This is a tooling issue, lock files solves the issue of instability when new versions of dependencies are released. If there is an issue with a new dependency version then don't update it and let the lock file keep it at the same version.

Hrmm but loock files are only working on upstream projects (the one that embed hackney), aren't they? This make the support of hackney i harder if i can't ensure the right deps are used. I mean, if people see an issue when using hackney, they won't blame at first a sub-dependency that have been updated transparently during their build, but hackney. So a ticket would be open first on hackney. It is afaik not a tooling issue in such case. It's a human issue. Just saying because a dependency is using a numbering doesn't mean it is actually following the rules of the semver specification. I can trust the dependency I code (which are most of the deps inside hackney). But not the rest. A release is only tested with some versions. Support can only be done on some versions. And it will require extra-effort to test a new version, of the deps. This will need to be planned or automated at least. I could simply tell to the users they have to use the version I locked myself, but it will be a bad UX somehow.

Anyway I hear you. I will try to fix it on the next release. I need to find a way to automate the testing of the new dependencies version though, as I plan to provide a better support of hackney.

[ericmj]

What are the dependencies of hackney that you don't trust they follow semantic versioning? If so we can look at them specifically and see if we can ensure they follow semver.

I think the main question is if it's more important to ensure that deps are locked to ensure that hackney is not affected if there is breakage when bumping a non-major version of a dependency. Or if it's more important / better that users will not have versioning conflicts when using hackney and its dependencies. I think the latter is more important and more common, we should be able to trust dependencies to not do breaking changes most of the time.

Anyway I hear you. I will try to fix it on the next release.

Thank you. This will be a great improvement for the ecosystem since hackney is so widely used in the community.

I need to find a way to automate the testing of the new dependencies version though, as I plan to provide a better support of hackney.

Some projects have nightly jobs that remove the lock file so that the latest dependencies will always be fetched.

[benoitc]

fixed in 4790e9f609348e5525fc2d6dd1a541f9ee9e7ff7. Thanks for the feedback.