8.0.0 release plan

[AA-Turner]

I intend to open Sphinx 8 for development either later today or tomorrow, with a release planned for the end of next week (though I'm open to arguments to delay).

This release would be only removing expired deprecations, dropping support for Python 3.9, and consequent refactorings -- I wouldn't expect any new features to be included.

A

cc: @sphinx-doc/developers @sphinx-doc/triagers

[picnixz]

I'd like to delay the release, unless you are willing to take over the deprecation in intersphinx (#12083) in case I'm not available next week (I'm finalizing the last bits of my final manuscript).

I fixed all conflicts in the PRs for that so it should be fine. Ideally, I would like to be able to review everything that will be release in 8.x before publishing the first draft, but I'll only be able to do so starting mid August. I think there are multiple people that are on holidays as well so it'd be better to wait a bit (for instance, if there are new bugs appearing due to 747).

[AA-Turner]

I was trying to avoid making a release in August, as that is typical holiday season (at least in Europe). I am happy to cover #12083 and #12087 if we don't delay.

Also of note is that Sphinx 8 will break breathe (breathe-doc/breathe#943, breathe-doc/breathe#984, breathe-doc/breathe#964, breathe-doc/breathe#977; all the same paths issue). @michaeljones / @jakobandersen are you able to merge any of these / make a new breathe release?

A

[chrisjsewell]

Thanks for the heads-up @AA-Turner!

Yeh I think, as long as all the known regressions from 7.4 are fixed, and it's only dropping deprecations,
we should get it out ASAP, to avoid further building up a backlog of issues/PRs for new things.

I've worked on intersphinx, I can also double-check those PRs if necessary

[picnixz]

Ah I see. Actually, #12083 is about removing the very old intersphinx format which was planned for removal in 8.x. But if you think we don't need to remove it at this point, no need to press it (I mean, we can always delay the removal by 1 version to avoid surprises).

[chrisjsewell]

I would also like for #12597 to be considered

[jayaddison]

Ah I see. Actually, #12083 is about removing the very old intersphinx format which was planned for removal in 8.x. But if you think we don't need to remove it at this point, no need to press it (I mean, we can always delay the removal by 1 version to avoid surprises).

This is about the format of the intersphinx_mapping configuration entry only, right? As in: we're not deprecating the v1/v2 inventory formats, but suggesting removal of an old-style config entry for remote mappings, which has emitted warnings since v6.2 onwards.

Refreshing my memory of #12087 in a few moments..

[picnixz]

This is about the format of the intersphinx_mapping configuration entry only, right

Yes. It was the very first way to specify intersphinx mappings without a named inventory. But the maintenance cost was really not easy and there are a lot of paths to be taken just to take care of un-named inventories. Also, it conflicted with the resolution algorithm (when you don't know which inventory to target...).

#12087 is about fixing an issue when you change the URL of your project (you end up having TypeError if you don't wipe out your cache). So it's a bug fix only (so it doesn't really need to be incorporated into 8.x, it's just that it uses the assumptions that I only have the new format, otherwise it's too complicated...).

[jayaddison]

Ok; I remember most of those details now. I'll have another read through them both to try to provide some additional support for the release (if we do that soon).

[picnixz]

I don't really care about the second PR but the one removing the old intersphinx format is definitely something that I would like to incorporate (at least, it would ease my life for future work).

[jayaddison]

I don't really care about the second PR but the one removing the old intersphinx format is definitely something that I would like to incorporate (at least, it would ease my life for future work).

Personally I am somewhat interested in both of them (I think the reproducibility fix from #12087 would be a nice clean transition alongside 8.x), so despite being tempted only to offer to support one.. I think I would prefer to try to understand and include both :)

[michaeljones]

Breathe is not really maintained at the moment. We're (rather passively) looking for funding for future development. Please don't delay any release for us. Sorry that the lack of maintenance on Breathe will result in some disruption though.