Release Caqti 2.1.2.

[paurkedal]

This fixes some bugs and updates some dependencies, most notably tls to version 1.0.0 for caqti-mirage.

Release notes: https://github.com/paurkedal/ocaml-caqti/releases/tag/v2.1.2

[paurkedal]

About the the CI run, what does "switch turned off" mean and should we worry about the resolution timeout?

On the latter point, my strategy has been to make internal dependencies as lax as possible, and only releasing packages which have changed. This reduces the number of packages, and makes it possible to mix Caqti packages with different versions to some extent, but I am not sure what effect it may have on the complexity of dependency resolution. I have noticed that other projects with multiple packages tend to use {= version} for internal version constraints, releasing a full set of packages on each release. Would that be preferable?

[hannesm]

About the the CI run, what does "switch turned off" mean

some internal CI failure - timeout or whatever. Sometimes it helps to "rebuild" that specific job.

and should we worry about the resolution timeout?

I guess this is a combination of the solver service getting overloaded, and the opam-repository growing and growing. Luckily soon [tm] there'll be some shrinking applied (see #23789).

On the latter point, my strategy has been to make internal dependencies as lax as possible, and only releasing packages which have changed. This reduces the number of packages, and makes it possible to mix Caqti packages with different versions to some extent, but I am not sure what effect it may have on the complexity of dependency resolution. I have noticed that other projects with multiple packages tend to use {= version} for internal version constraints, releasing a full set of packages on each release. Would that be preferable?

I do it sometimes this way, sometimes another way. Usually I try to release only the things that changed. But then, if in doubt, I rather release all packages than a subset. I think it is a question of taste.

[hannesm]

And the =version constraints help me at least to specify that "if you use a random version of mirage-crypto, don't expect another random version of mirage-crypto-ec to be compatible".

[hannesm]

I find this good to merge as well!

[paurkedal]

Thanks for sharing your experience about internal version constraints. Yes, it's also simpler, though it hasn't usually been an issue for Caqti (storing packages separate sub-directories and using git diff --stat v2.1.1..master helps). Hopefully shrinking solves the timeout issue, otherwise it might be worth revisiting what's the best practise w.r.t. constraints.