Add cabal-version advice to corresponding .cabal files

[sol]

This was part of the pre-flight checklist, which I would like to get rid of.

The original version of this was:

• make sure cabal-version of Cabal and Cabal-syntax is within the backwards compat range (and not too ancient, either).

I interpreted this as:

1. cabal-versions should not be too recent
2. there is no important reason to bump the cabal-version
3. We don't want to use an ancient cabal-versions (for any definition of ancient)

From what I understand, for a release, the only thing that is critical is that it is not too recent. If we make sure that we don't bump it too aggressively on master, then this will always be true.

So what does not too recent mean?

Naïvely, I assume we want the .cabal file to be parsable with any Cabal library that was bundled with any GHC version released within the last 5 years.

• I think technically, today this would be GHC 9.0.2 (2021-12-25) -> cabal-version: 3.4
• or, if we only go by the first minor release in a new major release series, then GHC 9.2.1 (2021-09-29) -> cabal-version: 3.6

https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history

If my understanding is correct, by which ever definition we go, I suggest that we stick with 3.6 (and don't go back to 3.4). But I also think that generally it makes sense to keep "LTS" GHCs in the support window.

So basically I suggest:

• stick with cabal-version: 3.6 for now
• going forward, bump less aggressively

Observations:

• Unless you want to use new features, or possibly for dogfeeding, there is no important reason to bump cabal-version
• cabal-version: 1.12 is completely adequate for many packages

---

Note, that the most recent version of this was less clear to me. With some mental gymnastics I could interpret it the complete opposite way around: https://github.com/haskell/cabal/wiki/Making-a-release/_compare/1848c319688beed33254efcf612d01c737c8a78e...72a2fa0f64643565e32994f7bdcdafb04bb4bee3

That's why I dug up the original version.

---

Template B: This PR does not modify behaviour or interface

E.g. the PR only touches documentation or tests, does refactorings, etc.

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions).

[ffaf1]

Please use the PR template (if you are doing PRs with gh, follow this).

[sol]

Please use the PR template (if you are doing PRs with gh, follow this).

I just checked the template again, I couldn't figure out what would apply to this PR specifically. The only thing that I'm relatively confident is, that it needs to be backported. I added the corresponding label.

Is there anything else specifically that you want me to do?

[ffaf1]

Is there anything else specifically that you want me to do?

Every time you open a PR, please select one of the two templates (Template B applies here). Check whichever box is relevant (in your case: the patch conforms to coding conventions), and strike parts that are not applicable to your PR (in this case, the PR does not involve CI).
This helps maintainers and reviewers a lot!

The only thing that I'm relatively confident is, that it needs to be backported. I added the corresponding label.

Very good. 3.18 has not been cut yet, so you might get lucky.

I see you have modified the “Making a release” wiki too. I would advise doing that after the PR lands on master, otherwise we risk having an out-of-synch release process.

I appreciate the care and work you are putting in streamlining releases.

[Mikolaj]

In a PR that just landed our GHC support window is narrowed to 3 years, not 5, so we need to support GHC 9.6 upwards (only the first major release counts, though you are right, point releases of LTS GHCs may be worth consideration, too). GHC 9.6.1 contains Cabal 3.10.1.0, so 3.10 is the relevant file format version. Did I get this right? If so, would it make sense to make the format 3.8 is both .cabal files?

[Mikolaj]

Regarding the intent of the pre-flight checks point in question, I think you deciphered it right regarding backward compat and the main motivation was to avoid keeping very old format versions, but not overdo it. There are many reasons to avoid ancient format versions; a few off the top of my head:

• it makes newcomer cabal contributors think they can't use modern features in the cabal project .cabal files
• it makes Haskellers who happen to look at our .cabal files (or even copy-paste them to their projects or read them as the best example, straight from the horse's mouth --- it does happen) think that using old format versions is somehow prudent and so indirectly it discourages them from using new cabal features
• it prevents our CI and us from dog-fooding newish format features

I think your changes document the constraints on format well and in the right place, but how do we ensure the format gets bumped often enough? BTW, that also applies to the .cabal file of cabal-install, etc.