I’ve asked Zubin about this, to which he replied: A deprecation warning is not a critical bug that warrants the effort and pain of a whole new release, including costs for tooling developers, CI systems and general ecosystem fragmentation over and above the direct costs of producing a release. I still think a deprecation coming in 9.14.2 is worth it, even if released only a few months from now. To add to my points before, many folks wait for the .2 release before upgrading to a new major version. Cheers, Rodrigo
On 15 Dec 2025, at 09:10, Simon Peyton Jones
wrote: Is there a reason we can’t have a 9.14.2 release with just the deprecation warning?
Rodrigo can you ask Zubin about this? There are non-trivial overheads associated with a release. But a very minor release like this might have much smaller overheads?
I suppose the goal would be that the deprecation is embodied in a released GHC, much sooner than awaiting for a critical mass of bug-fixes to accumulate.
Simon
On Sat, 13 Dec 2025 at 05:14, Moritz Angermann
mailto:moritz.angermann@gmail.com> wrote: Is there a reason we can’t have a 9.14.2 release with just the deprecation warning?
On Sat, Dec 13, 2025 at 1:39 PM Jakob Brünker
mailto:jakob.bruenker@gmail.com> wrote: Sounds like we're converging on that compromise. Any objections to accepting the proposal with these provisions? - Deprecation would start whenever 9.14.2 comes out (probably not for some months) - the change would take effect with 9.16 in about six month
If not, I'll take this as consensus by December 16.
Jakob _______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org mailto:ghc-steering-committee-leave@haskell.org
ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org