stack: bump oldest to lts10

[juhp]

Let's not sweat it/worry if lts9 is failing.

(Btw If it were me I would just go with the final minor release:
I don't think users are that interested in building with lts-x.0.)

pps I had pondered even to bump to lts11...

[juhp]

Seems to work okay :)

[gelisam]

I don't think users are that interested in building with lts-x.0

Remember, the purpose of oldest-supported-lts.yaml is not to advertise which range of lts versions are supported, but rather as a hack to make it easier to update the lower bounds in the cabal file.

I want to support both cabal and stack users, and cabal users need accurate version bounds. I used to binary search over all possible versions in order to find the oldest version of a dependency with which my code still works. Doing that for each dependency was a lot of work, so I settled for a compromise: I binary search over all lts releases to find the oldest lts with which my code still works, then I use its versions as the lower bounds for all my dependencies.

For that purpose, lts-x.0 is better than lts.x.<latest> because it pins older versions.

[gelisam]

Let's combine the two build steps into one and update all the lower bounds in the cabal file to match the versions in lts-10.0

[juhp]

Sorry, I am not a fan of having arbitrary hard bounds: for my projects I only add bounds that I know are actually necessary.
But sure feel free to just restrict them if you want.

[gelisam]

feel free to just restrict them if you want

I do want to, and two years later, I finally did it! 🙃 #278

More seriously: I think I am due for a new approach to version bounds, so maybe you can tell me more about this "only add bounds that you know are actually necessary" approach? Does that mean that you keep the lower bounds untouched until somebody reports that cabal was able to find a build plan but the code didn't work?

My goal with the current setup was to be quite conservative (almost never allow cabal to find a build plan which later fails with a compilation error) while still minimizing the amount of effort. Using both upper and lower bounds which are tested in CI would be even more conservative, but it would be more effort because it would involve a lot of churn bumping upper bounds. I was hoping that a monthly CI run would allow me to quickly detect when my upper bounds (or lack thereof) are too loose, at which point I can release hackage revisions and remain within the build-plans-do-not-fail zone.

Alas, I didn't count on:

1. GitHub disabling my monthly CI runs after a couple of month
2. getting so busy that I ignored the monthly CI failures I did get

as a result, my upper bounds were way too lose and have remained so for years :(

[gelisam]

Merged as part of #278