Lower cabal-version back to 1.18

[ninioArtillero]

Diff.cabal declared cabal-version: 3.14 solely to use the new extra-files field for bundling Diff-liquidhaskell.cabal in the sdist (see #45). However, such version is not supported by Hackage and could break dependency solving for some comsumers.

Switch to extra-source-files, which achieves the same sdist packaging with no functional difference for this use case, and drop cabal-version back to 1.18.

This also requires switching the license field from the SPDX identifier BSD-3-Clause back to the legacy BSD3, since SPDX license expressions aren't recognized before cabal-version: 2.2.

Diff-liquidhaskell.cabal is also lowered to this spec version, to ensure the same toolchain is compatible.

[ddssff]

This looks like it should help.

[ddssff]

Should I merge 2.0.0 into master? And upload 2.0.1 to hackage.

[ninioArtillero]

@ddssff I think so, but I'm not acquainted at all with hackage-upload quirks. I would try make sure everything is aligned within #47 before merging:

1. The package version in the cabal file (already switched to 2.0.1). ✔️
2. An entry for 2.0.1 in CHANGELOG.md, just stating that cabal spec was reverted from 3.14 to 1.18 for compatibility.

This is all supposing 2.0.0 can't be fixed on Hackage other than uploading a new version, so everything gets bumped to 2.0.1 as proposed.

[Bodigrim]

There is little point of going all the way to 1.18, clients with Cabal < 2.0 are not served by modern Hackage server. So even very conservatively you can use 2.0, but practically I'd put 3.10, which is the version of Cabal at Hackage build machine (https://github.com/haskell-infra/hackage-doc-builder-config/blob/master/flake.lock).

[ddssff]

Sorry I've been jumping the gun. I will continue making minor version changes.

[ninioArtillero]

Perhaps we can keep it like this (changes are already merged), and make a bump to 3.14 (so that the originally proposed extra-files field can be used) once that is supported.

BTW, is the spec version used by the Hackage server the effective upper-bound for supported versions?

Also, it is not clear to me what reasons could we have to be conservative about this version number. Wouldn't some consumers be affected by bumping to 3.10? Are there existing documentation on best practices?

[Bodigrim]

BTW, is the spec version used by the Hackage server the effective upper-bound for supported versions?

Hackage server itself at the moment uses Cabal-the-library 3.16 (you can see it in the footer of any package page such as https://hackage.haskell.org/package/Diff), so the original 3.14 was absolutely fine. If it was too new, Hackage would simply reject the upload as unparseable. It's the documentation build server which lags behind at the moment and still uses Cabal-the-executable 3.10. So to be honest I would not revert anything in the first place, just uploaded the documentation manually and leave it be; at some point the doc builder will be upgraded.

Wouldn't some consumers be affected by bumping to 3.10?

If consumers are using Cabal-the-executable 3.8 (which is 5 major versions behind the last release of 3.18), I imagine they are not exactly looking to upgrade Diff to the latest and greatest.

---

No active harm in having cabal-version: 1.18, so I would not do another minor release for now.

[ddssff]

We have a project that is still stuck on Cabal-2.4, so you never know. And I'm using the latest Diff in it! (Its because of the ghcjs -> javascript back end transition.)

[ninioArtillero]

@ddssff Apparently the 2.0.0 version raised many errors on the Ormolu CI (but 2.0.1 is worked just fine), perhaps it should be marked as broken in Hackage.