> Breaking changes caused by new exports could be mitigated
with a library package or a GHC plugin with such auto refactoring
functionality :
All of this is true. But from my side the worry here is less the
effort required to fix such issues.
Rather it's that users need to take any action at all when
upgrading from ghc-9.X.Y to ghc-9.X.Y+1 in order for their
projects to continue to compile.
Our goals here are:
* Ensure bug fix releases of libraries are shipped with GHC
without requiring maintainer attention.
* Try to keep breakage for users minimal.
In concept the idea of only bumping sumperminor versions makes
sense, as those typically don't contain any breaking changes.
But after looking through some of the changelogs of boot libraries
it seems like *many* bug fixes are currently released as minor
releases. As a consequence I don't see applying this policy only
to superminor versions as productive unless the release practices
of boot libraries change significantly which seems unlikely.
Similarly in theory we can disregard concerns about breakage with
a reference to best practices or paint users as responsible for
open
imports. But that won't change the fact that it's common practice
to use open imports and as a result there will be breakage from
such
changes.
So this leaves us with:
## Always bump minor versions [unless there are objections].
This ensures bug fixes make it into releases reliably with little
maintainer burden, but will result in breakage for some projects
when upgrading from ghc-X.Y.Z to ghc-X.Y.Z+1.
Breakage from such issues tends to be immediately observed as tied
to a ghc upgrade, and as such we tend to more reliably hear of it.
## Never bump minor versions [unless explicitly requested by
maintainers of the library, or deemed necessary by ghc
maintainers].
This reduces breakage from added imports, but means ghc might ship
at times with libraries which contain bugs for which a fix already
existed. It is hard to accurately judge the cost/benefit of this
approach. As such bugs typically are discovered once applications
are deployed and as ghc devs we might never hear of issues caused
this way.
Some projects are also locked into boot library versions, and
might want to use newer versions for non-bugfix reasons.
-----------------
Personally I think we should bump minor versions by default
despite it occasionally causing breakage. However I think we
should also be willing to avoid a bump if it causes a large amount
of known breakage while not providing any bug fixes.
For example we should probably not upgrade point releases from
text-2.1.1 to text-2.1.2 as the addition of `show` causes breakage
and there seem to be no bug fixes in the release, unless the
library authors request us to do so.
On Wed, 27 Nov 2024 at 11:58, Tom Ellis <tom-lists-haskell-cafe-2023@jaguarpaw.co.uk> wrote:Thanks Adam,
I'm not too familiar with the GHC-side requirements here, but I wonder
if we can approach this issue from a different direction: is there
something we can do to help boot libraries avoid breaking changes?
Tom
Breaking changes caused by new exports could be mitigated with a library package or a GHC plugin with such auto refactoring functionality :
* Uniquely qualify (i.e., leave no different modules similarly qualified in the same module) each imported module and each imported symbol.
This refactoring should be possible in code which already compiles.
It would not require syntax / grammar changes.
Something similar to smuggler2 package.
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs