Release 1.0.10

[ulidtko]

As followup to:

• Dropping maintenance, takeovers welcome #79
• Support GHC 9.10 #82

[andreasabel]

LGTM!

NB: In principle, all these changes should be revisionable (staying at 1.0.9).

[andreasabel]

Agreed!

[ulidtko]

Published v1.0.10.

@Qqwy I don't expect any issues when updating, but please LMK if any difficulty whatsoever arises.

@andreasabel I can agree this technically could've been a revision of 1.0.9 — but as a consumer of the package, I would really expect a genuine version bump :) Rare things are worse than "same but different" versions...

[andreasabel]

Yes, as soon as you raise a lower bound (like base to 4.9`) there should be a version bump, not a revision.
In general, only relaxations and corrections of actually wrong bounds may be revisions. Otherwise correct build plans will be destroyed.

[ulidtko]

@andreasabel just curious, do you mean that build plans get persistently saved somehow?.. My understanding up until now was, that build-plans are "ephemeral", produced by cabal solver on-demand, recomputed from package index state + constraints every time anew. Isn't that so?.. Destroyed how?

I'd checked hackage-trustees guidelines — and there too, it says anything in the sdist tarball (e.g. README) except some fields of the cabal-file, can't change in revisions. Per these guidelines, commit 009a688 should've been a version bump:

─────────────────────────────────────────────────────────
modified: src/Distribution/Extra/Doctest.hs
─────────────────────────────────────────────────────────
@ src/Distribution/Extra/Doctest.hs:128 @ import Distribution.Types.LibraryName
        (libraryNameString)
 #endif
 
-#if MIN_VERSION_Cabal(3,6,0)
+#if MIN_VERSION_Cabal(3,5,0)
 import Distribution.Utils.Path
        (getSymbolicPath)
 #endif
@ src/Distribution/Extra/Doctest.hs:334 @ generateBuildModule testSuiteName flags pkg lbi = do
               <- mapM makeAbsolute
                $ compAutogenDir           -- autogenerated files
                : (distPref ++ "/build")   -- preprocessed files (.hsc -> .hs); "build" is hardcoded in Cabal.
-#if MIN_VERSION_Cabal(3,6,0)
+#if MIN_VERSION_Cabal(3,5,0)
                : map getSymbolicPath (hsSourceDirs compBI)
 #else
                : hsSourceDirs compBI

because that's a source-code change, not just cabal-file metadata.

In the same trustees repo, there's a policy.md that apparently encourages retroactive bounds tightening. It also says bounds weakening "should be done carefully"... and doesn't rule it out.

I'd also read this in cookbook.md:

Another problem [...] If such install-plans are retroactively prohibited, this results in a bad user-experience, and results in violation of the invariant that a meta-data revision shall not result in existing install-plans becoming illegal.

Are you referring to this issue? When from a user perspective, something used to build, but after a revision somewhere in dependencies, cabal solver would give up?

[andreasabel]

just curious, do you mean that build plans get persistently saved somehow?

Well, for one you can do this with cabal freeze. Further, versions are pinned in stackage snapshots. So if a build once version with version X of a package, it should not become impossible with a revision of X.

I'd also read this in cookbook.md:

Another problem [...] If such install-plans are retroactively prohibited, this results in a bad user-experience, and results in violation of the invariant that a meta-data revision shall not result in existing install-plans becoming illegal.

Yeah, this is a good quote, that basically sums it up.

commit 009a688 should've been a version bump:

modified: src/Distribution/Extra/Doctest.hs

Yes, you cannot release code changes as a revisions, the uploaded tarball isn't modified by a revision.