Allow GHC-9.6

[ysangkok]

It seems like warnings can't be turned off for doctest-0.21, so I fixed them instead. Passing -Wno-type-defaults would also work, but I only got it to work in a way that would also affect compilation. I think it is nice to have more explicit types, so I don't really consider the fixed warnings a problem.

Closes #1672

[voidus]

I added a few minor nitpicks, mostly about potentially adding comments explaining why things are the way they are. Besides that, this looks like a pretty straightforward change to me.

I do have to add that I'm just a random guy and not a servant maintainer :)

[ysangkok]

Thanks very much for your review @voidus , I think I have addressed your concerns. Please let me know if that is not the case.

[benz0li]

@ysangkok @jkarni Is there a timeline for this merge?

(GHC v9.6.2 has already been released)

[ysangkok]

@benz0li There is no timeline but I think it would be best to address #1679 first. If we develop with a failing CI, there is a higher likelihood that we'll miss something.

[maksbotan]

@ysangkok do you plan to do Hackage revisions to allow 9.6? I can do that if you want me to.

[ysangkok]

@maksbotan I don't think a revision will work, since SourceT.hs in e.g. v0.19.1 isn't compatible with the new transformers release, which is why I previously tried addressing that in #1627, and this PR further adjusts this.

I don't think we have had a release since #1627 . But I do think it is time to make one. I just don't have the Hackage permissions to do that.

[maksbotan]

@ysangkok can you give me commit hash and a version you'd like to set? I'll make hackage release hopefully tomorrow

You plan 0.19.2? 0.20?

[ysangkok]

@maksbotan It has to be a new major version, so 0.20.0, since we have had multiple breaking changes. I think the latest commit, 88408e4, should be released. Thank you very much for your work!

[maksbotan]

Okay! I'll try to do it this evening. Do you have a list of those changes btw? Compared to 0.19.1.

[ysangkok]

I have always thought that we need to use the changelog.d directory for generating the changelog. But it seems that currently the directory contains changelogs for already-released releases:

servant/changelog.d $ for i in ????; do
   echo -n $i;
   COMMIT=$(git log -n 1 --pretty=format:%H -- $i);
   TAGS=$(git tag --contains $COMMIT | tr '\n' ' ');
   echo " $TAGS";
   done
1432 v0.19 v0.19.1 
1469 v0.19 v0.19.1 
1477 v0.19 v0.19.1 
1529 v0.19.1 
1556 v0.19.1 
1569 v0.19.1 
1571 
1573 
1580 v0.19.1 
1584 
1589 v0.19.1 
1593 
1595 v0.19.1 
1606 
1638 
1646 
1649 
1661 
1665

I think for this release, we can include the changelogs that don't have a tag after them, so e.g. #1571, #1573, #1584 and so on. It's a shame that the changelogs for v0.19.1 do not appear to include all the changelog entries listed above.

[maksbotan]

I've made hackage revisions for:

• servant-client-0.19
• servant-docs-0.12
• servant-foreign-0.15.4
• servant-http-streams-0.18.4
• servant-auth-client-0.4.1.0
• servant-auth-docs-0.2.10.0
• servant-auth-server-0.4.7.0
• servant-auth-swagger-0.2.10.1
• servant-auth-0.4.1.0

These do not require version bumps as no code was changed.

Will proceed with 0.20 for servant, servant-server, servant-client-core, servant-swagger later this day.

[ysangkok]

That might work, but I think it might be best to make a release for servant-client, since I think its version number was previously always in sync with servant-client-core. If there is a servant-client-core-0.20, it wouldn't be accepted by servant-client-0.19 (revision 6, just published), since it has the bound servant-client-core >=0.19 && <0.19.1.

We must weigh saving space on Hackage with how confusing the differing version numbers get...

[maksbotan]

Of course, when I start doing 0.20 bumps, I'd have to bump servant-client and such packages as well. I'm not going to leave servant-client-0.19 + servant-client-core-0.20 :)

[ysangkok]

Great! By the way, I think the tool used to read changelog.d is https://github.com/fgaz/changelog-d