Bump project version from 3.11 to 3.13

[sheaf]

This PR bumps the Cabal version from 3.11 to 3.13, as the release branch for 3.12 has already been cut.

[geekosaur]

Looks okay to me, but CI thinks we're still depending on 3.11 somewhere.

ETA: correction, cabal-install is of course still 3.11 for this, but it's using Cabal-syntax 3.10.1.0 for some reason.

[sheaf]

Looks okay to me, but CI thinks we're still depending on 3.11 somewhere.

Yeah there's still some work to do, I don't know how these bumps were done in the past.

[Mikolaj]

@sheaf: here's the latest PR that does that (but it uses version 3.12 and this one needs 3.13): #9788 and here's the last PR that did this for master branch: #8844. Hope that helps.

[Mikolaj]

And it's also described in https://github.com/haskell/cabal/wiki/Making-a-release#c3-bumping-version-numbers

[sheaf]

I've updated the bootstrap plans and added a few missing version bumps. Let's see how far we get now.

[Mikolaj]

BTW, since this ticket was opened, the release checklist has changed and now also these steps need to be done on branch master (unless done already; probably a half is): #9729

Edit: but it doesn't need to be in this ticket. They are only vaguely related.

Edit2: Actually, now that these steps are separated, they are best done on release branch and forwardported, [edit: actually, doing them on master and backporting is what the documentation says and it's probably correct, but they seem quite separate anyway] so probably nothing to do here. However, previously some of them were part of the https://github.com/haskell/cabal/wiki/Making-a-release#c3-bumping-version-numbers section linked above, so it's worth nothing they are now gone and why.

[Mikolaj]

This is a part of the release process, so let's fast-track, unless anybody needs more time to review (I will now).

[Mikolaj]

@mergify rebase

[mergify]

rebase

✅ Branch has been successfully rebased

[ulysses4ever]

Proliferation of index-states is concerning. Ideally, it'd be done with import's.

[geekosaur]

I think #9901 makes that difficult currently.

[ulysses4ever]

Yeah, I haven't put enough thought into possible workarounds. I guess, this PR should be merged asap, and we can think about it more, later.

[Mikolaj]

The first release from these series will be exceptionally 3.12.0.0, but it's indeed unlikely anybody is bootstrapping until cabal-install is released in 3.12.1.0.

[Mikolaj]

Thank you very much!

[Mikolaj]

Sigh. I will report about this duplicated index state and the breakage that necessitated this new file in #9901

[Mikolaj]

I forgot it now merges after only a few jobs pass for an uknown reason. I will monitor that the rebased CI finishes.

[geekosaur]

Interestingly, there is nothing about this in the Mergify rulebase, so it's presumably a code change in Mergify. I wish I'd been able to find documentation on mergify.com, but it seems to all be marketing information. ☹️

[Mikolaj]

I suspect it's related to branch protection rules in Settings, but they do look fine as well.

[ulysses4ever]

I forgot it now merges after only a few jobs pass for an uknown reason. I will monitor that the rebased CI finishes.

I missed when this problem appeared. I am reasonably sure that it's due to #9355. After it, Validate post job always "succeeds" instantaneously and can fail later on on the real runs, if there are any, but Mergify won't wait and once it sees "success" there, it merges right away. /cc @BinderDavid

[Mikolaj]

@geekosaur: I've bumped your repo permissions to Maintain. I wonder if you can see the Settings tab now.

[ulysses4ever]

I wish I'd been able to find documentation on mergify.com

How is https://docs.mergify.com/?

[BinderDavid]

Should we open a separate issue for this? I fail to see who exactly is responsible here: mergify or the github branch protection rules. https://docs.mergify.com/workflow/actions/merge/ for example is quite unclear and vague:

Mergify always respects the branch protection settings

but also

The following protection settings are only partially supported by Mergify:
Require status checks to pass before merging;

When I implemented the logic for the faster documentation CI I focused on getting the code correct for the branch protection logic that Github uses. I thought that mergify only provides additional convenience features on top of Github's rules, and that it can't override something that Github branch protection forbids, but now I am not so sure anymore.

Edit: I now recall that https://github.com/orgs/community/discussions/13690 is the relevant thread that describes the annoying Github restriction which made the workaround necessary in the first place.

[ulysses4ever]

@BinderDavid thanks for a prompt response! I think no one, including the approvers of your PR, could have anticipated this interaction between GH and Mergify (assuming this is the real reason of the problem, which is not a given). Indeed, opening a separate ticket would be good.