Timeline for next Cabal release (support for profiled dynamic way)

[mpickering]

It would be very good if there could be a release of the Cabal library far in advance of the next GHC release so that hadrian can be built with a released version of the Cabal library.

For context, hadrian is one of the build systems which is implemented on top of the Cabal library (like cabal-install and stack) which is specialised for building ghc and it's libraries. Packagers must first build hadrian before they build ghc so having an easy bootstrapping story for hadrian is very important.

Since we are adding support for the profiled dynamic way to the ecosystem, at the moment hadrian relies on a unreleased version of Cabal as I added supported for profiled dynamic way in #9900. However by the time the next GHC release happens it would be much better if hadrian could be built with a released version of Cabal. This would simplify the bootstrapping story for some distributors.

[ulysses4ever]

Just to be clear (looking at #9900): it has to be a major release (e.g. 3.14), it looks like.

[mpickering]

Yes it would probably have to be a major release.

• There could be a release of Cabal-3.14 and cabal-install-3.14 completely independently of ghc-9.12 and a long time before.
• There could just be a release of Cabal-3.14 (simpler, no binaries to produce) well before 9.12. Then Cabal-3.18 could be released along with cabal-install-3.18 (skipping cabal-install-3.16).

[Mikolaj]

Won't we cause users grief, as in https://github.com/haskell/cabal/issues/9917, if we release Cabal-3.14 without cabal-install-3.14? Or would the grief manifest only when GHC 9.12 with Cabal-3.14 is released, so we'd need to have cabal-install-3.16 ready for GHC 9.12 (which implies two major cabal release per one GHC release, while we struggle to do 1-1 currently)?

[ulysses4ever]

@Mikolaj the latter, I think:

the grief manifest only when GHC 9.12 with Cabal-3.14 is released,

provided there's no matching cabal-install release. But we could release it somewhere around the GHC release, hopefully.

Now, it's not clear to me if Matt suggests yet another release of the library with GHC 9.12 (that would be 3.16 but he says 3.18 for some reason). But just like Mikolaj seems to imply, two major releases of the library per one GHC release cycle seems too much. So, I'd suggest GHC 9.12 is released with Cabal 3.14, which we could produce well in advance. And closer to the GHC 9.12 release date we get around to releasing cabal-install-3.14.

How does that sound?

[ulysses4ever]

On today's meeting, Mikolaj made a good point that if we don't make another release of the library closer to the GHC 9.12 release, we'll have to go through a long chain of backports, which is more painful than "just" making a new release of the library.

In light of this, I suggest we:

• release the library now'ish(*) (3.14)
• library and tool (both 3.16) closer to GHC 9.12.

(*) when we have a volunteer :-)

[Kleidukos]

I volunteer for 3.14

[ulysses4ever]

@mpickering is there an estimate for when 9.12 drops?

@Kleidukos let me (and everybody, I assume) know if you need a hand in driving particular subtasks in the checklist! Last time it worked pretty well.

[mpickering]

@ulysses4ever "We are in the process of planning the GHC 9.12 release. The tentative schedule is a fork date in mid September with a final release in late November."

[ulysses4ever]

Good! I believe Hécate has a plan.

[wz1000]

I think it makes sense to have a Cabal release well before the GHC 9.12 release so that the vendored submodule for hadrian can be removed, and then we can finalise another Cabal release just before the 9.12 release (in November) which properly adds support for GHC 9.12 and language extensions etc.

[ulysses4ever]

@Kleidukos volunteered for the next release. @Kleidukos do you need help?

That said, with our glacial pace, it looks increasingly unlikely that we can make two releases before the end of November (three months from now).

[wz1000]

If there is going to be single release, I can prepare a list of new language extensions and other GHC changes cabal needs to adapt to in the coming weeks, but we will need a Cabal release by end of September to ensure we can publish GHC alphas.

[Kleidukos]

Let's aim for two releases, the first one ought to be easier than the second in terms of supporting the next GHC.

@ulysses4ever yes, I will resume the attribution of tasks to myself and others to do the next release.

@wz1000 GHC needs the Cabal libraries only or the executables too?

[wz1000]

only the libraries.

[Kleidukos]

Ok thank you!

[ulysses4ever]

@wz1000 having some deadline for the next Cabal release (e.g. end of September as you say above) is very helpful, thank you. Before, we only heard "we need it earlier than usual", which is not actionable.

[ulysses4ever]

@Kleidukos re: the executable: there needs to be a release before the GHC release (with 3.12, we learned all too well what happens otherwise), so before the end of November. Mikolaj suggested that it may be easier to make another release of the library as well closer to that date (because of easier backports management). If we can get things going smoothly soon, this may actually happen :-)

[Mikolaj]

Let's make a post-mortem of 3.12 during the nearest cabal chat and think how we can avoid the murderous backporting crunch this time and then everything else is easier.

[geekosaur]

I'm at least trying to get PRs backported shortly after they go into master; you've probably seen me tagging them when they come in, as a reminder.

[geekosaur]

…Although there's no backporting for the next release yet. Until it's branched, there isn't much to be done. Possibly when we branch it, we should go into a "slush" to minimize the number of things that need to be backported to it.

[Mikolaj]

Yes, since 3.12 is the Somewhat Longer Term Support release, it makes sense to backport early and often. But we can agree on a different backport policy for 3.14, e.g., the opposite one: cut the release branch as late as possible, backport only the most urgent and not too risky bug fixes (fixes introduce new bugs), release 3.16 as early as possible with any bug fixes that were too hard/risky to backport to 3.14 (given that we don't backport other things to 3.14, so conflicts are to be expected). Or something in-between.

[Kleidukos]

Yes, 3.14 and 3.16 are not LTS candidates as we speak, the same generous backport rules don't necessarily have to apply (unless circumstances force our hand).

[wz1000]

@Kleidukos just a reminder that the plan is still to have a 3.16 release of Cabal that will ship with GHC 9.12. It would be good to have a timeline for this release so that we can ship GHC 9.12 in November.

[Kleidukos]

You mean 3.14, and yes thank you for giving us the date of release. :)

[ulysses4ever]

Haven't 3.14 dropped? I'm confused..

[Kleidukos]

@ulysses4ever we have yet to release cabal-install and cabal-install-solver v3.14.

[ulysses4ever]

I realize that but this can't be related to what sheaf says:

the plan is still to have a 3.16 release of Cabal that will ship with GHC 9.12

We don't ship cabal-install (much less the solver) with GHC, do we?

[Mikolaj]

Yes, we don't, but there are going to be problems (to do with Custom) if users get Cabal 3.14 from GHC but can't get cabal-install >= 3.14 to match it.

[wz1000]

I discussed with @Kleidukos and the plan is for a minor release for Cabal(-syntax?) 3.14 in time for GHC 9.12.

[Mikolaj]

That can't be right. There has to be a cabal-install release around that time. 3.14, if possible, 3.16 if PvP forces us to. This was discussed at cabal devs meetings, but perhaps people were absent or forgot or there's miscommunication.