Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

4.0.0 release plan #9056

Closed
tk0miya opened this issue Apr 4, 2021 · 60 comments
Closed

4.0.0 release plan #9056

tk0miya opened this issue Apr 4, 2021 · 60 comments
Milestone

Comments

@tk0miya
Copy link
Member

tk0miya commented Apr 4, 2021

According to our annual release cycle, this April is time for the major release.
I think this schedule is good for the release. What do you think?

  • Apr 10th:
    • Beta release (feature freeze)
    • call for translation
    • Create a new branch: 4.x and 4.0.x
      • 4.x will be used for develop 4.1
      • 4.0.x will be used for develop 4.0.0 (feature freezed)
  • Apr 24th: final release

Any comments?

Note: issues marked as 4.0.0: https://github.com/sphinx-doc/sphinx/milestone/74

@shimizukawa
Copy link
Member

㊗️

@ericholscher
Copy link
Contributor

ericholscher commented Apr 6, 2021

Is it possible to have the release done on a weekday, so that if major issues are hit with RTD or other downstream users, we can be around to fix them? I realize it's a trade off between folks who are doing this work in their jobs vs. free time -- but I do think it might be best to ship them on a weekday, if possible.

We just hit this with the docutils release, and woke up Monday morning to a number of bug reports, so it would be great to coordinate this stuff a bit more. Certainly some of this can be caught in testing, but there's such a widespread user base, there will always be edge cases we can't catch in beta.

@grubert
Copy link

grubert commented Apr 6, 2021 via email

@tk0miya
Copy link
Member Author

tk0miya commented Apr 7, 2021

I don't know I will have time on weekdays. But it's not impossible.

@jakobandersen
Copy link
Contributor

I'm hoping to get #9023 and #8313 done for v4 due to (semi-)breaking changes. However, the latter requires #8929 to avoid breaking existing intersphinx functionality for the C domain. @tk0miya, are you fine with the design of it?

@tk0miya
Copy link
Member Author

tk0miya commented Apr 7, 2021

Now, I don't have time to review #8929 in detail. But I think env and domains should not be coupled with intersphinx. So I'd like to implement it on 4.1.

@jakobandersen
Copy link
Contributor

It is indeed an icky coupling with the domains, though it is difficult to get around. Ok for me to wait for 4.1.

@tk0miya
Copy link
Member Author

tk0miya commented Apr 7, 2021

Thank you for understanding :-)

@ericholscher
Copy link
Contributor

ericholscher commented Apr 8, 2021

@tk0miya @grubert Appreciate the comments here. I fully appreciate the constraints involved around working on this stuff, and want to specifically thank you for your work on these projects. Having it released on a weekday is not a huge requirement, and becomes less of an issue if we test beta releases more prior to them going out to at least find any widespread issues.

I'd love to offer some help at the RTD level to see if we can possibly increase testing of betas and integration of our the entire stack (docutils -> Sphinx -> Sphinx themes -> RTD) prior to major releases. Does docutils have a similar place for us to track beta timelines? It would be great to be able to coordinate releases of these tools a bit better, if that isn't a burden on the maintainers, but I think at least working on the RTD side to do more testing prior to release is something we can commit to without adding workload to you.

@tk0miya
Copy link
Member Author

tk0miya commented Apr 8, 2021

I believe docutils-develop list is a good place to know the schedule of the release. I first heard the plan of the 0.17 on the list.
https://sourceforge.net/p/docutils/mailman/message/37217330/

(But I couldn't confirm it well because of lack of time...)

@return42
Copy link

return42 commented Apr 8, 2021

I believe docutils-develop list is a good place to know the schedule of the release.

There is also a section "Future changes" in the https://docutils.sourceforge.io/RELEASE-NOTES.htm which could give one some hints about changes in the next release .. but in lack of time I do not check it regularly.

I think it is the best to pin the docutils version, to something what is widely tested (or even better a range of versions >=0.12,=<0.16)

'docutils>=0.12',

@Blendify
Copy link
Contributor

Blendify commented Apr 8, 2021

I think it is the best to pin the docutils version, to something what is widely tested (or even better a range of versions >=0.12,=<0.16)

'docutils>=0.12',

I agree here with adding a range of versions, these seems like the best approach to prevent issues in the future.

@grubert
Copy link

grubert commented Apr 9, 2021 via email

@tk0miya
Copy link
Member Author

tk0miya commented Apr 9, 2021

I think it is the best to pin the docutils version, to something what is widely tested (or even better a range of versions >=0.12,=<0.16)

Who confirms it? Who will do widely test? That sounds great if you'll do that! Contributions are always welcome.

@return42
Copy link

return42 commented Apr 9, 2021

Who confirms it?

RTD can test .. may be others with a huge base of documents .. and yes I am also willing to help and contribute. I have several projects in which I can test upgrades of docutils (or other stuff).

Or we are building a suite of "test documentation" .. if something like this not already exists.

If I can help I will do it .. but I do not have perfect concept at hand I could suggest .. comments, thoughts?

@tk0miya
Copy link
Member Author

tk0miya commented Apr 9, 2021

If you can't accept the broken of OSS packages, please pin your packages now. I think there are no perfect programmers. So bugs are usually appeared in the new packages, not only docutils. I guess Sphinx-4.0 also contains some bugs and troubles. So you must pin the version of Sphinx also ASAP. And please wait for it is widely tested.

@ericholscher
Copy link
Contributor

ericholscher commented Apr 9, 2021

@tk0miya I think the argument is more that we should have the testing flow upstream from released packages. The way it currently works:

  • docutils releases betas nobody tests
  • docutils releases a final version, which gets installed by everyone because sphinx doesn't pin it
  • sphinx is currently broken on the current version for new users, who might have no idea what docutils is
  • users scramble to fix sphinx and get a release out that fixes things in a few days

I think the proposed workflow is:

  • docutils releases a final version, but it isn't automatically used by sphinx users
  • users who understand python packaging can install latest docutils with the latest sphinx, find issues and file bugs
  • the new version of sphinx comes out that supports the latest docutils after users have been trying it for a few weeks

This moves the burden of discovering bugs onto advanced users who understand the ecosystem instead of new users who are setting up a broken environment while the releases aren't compatible.

Of note, we could use the existing RTD theme repo as a test case for this: https://sphinx-rtd-theme.readthedocs.io/en/stable/demo/demo.html#id29

@jakobandersen
Copy link
Contributor

  • users who understand python packaging can install latest docutils with the latest sphinx, find issues and file bugs

This seems like the weak link of this strategy. From a pure Sphinx perspective, isn't this basically just another kind of docutils beta in disguise?

Is there a way we can have a CI test with the newest development version or beta docutils? similarly to how we test against the development version of Python, whatever state it is in. Then it is "just" a matter of enough test coverage.

@tk0miya
Copy link
Member Author

tk0miya commented Apr 11, 2021

From now on, the 4.0.x branch is feature freezed. Please let us know if you still have new features for 4.0.0.

I have two issues.

@jakobandersen
Copy link
Contributor

From now on, the 4.0.x branch is feature freezed. Please let us know if you still have new features for 4.0.0.

@tk0miya, it would be great if we could get #9023 done for 4.0.0. It dramatically changes the C and C++ HTML output so one could consider it somewhat breaking. There are additional next issues with formatting and C++ features that depends on it as well. Do you have a minute to double check my response to the remaining issues?

@tk0miya
Copy link
Member Author

tk0miya commented Apr 11, 2021

@return42 Sorry for confusing you. I'd not like to confuse you. But my poor English skill (and discussion skill) would cause my misunderstanding. I really don't understand the goal of the discussion with you yet. If it's the same as @ericholscher said, we have to discuss how to do it (about the workflow).

@return42
Copy link

If it's the same as @ericholscher said, we have to discuss how to do it (about the workflow).

Ah, OK, sorry for being impatient .. yes, lets discuss how we can establish a workflow for .. may be we better discuss this in another thread, not dedicated to the Sphinx 4.0.0. @ericholscher what do you think?

@tk0miya
Copy link
Member Author

tk0miya commented Apr 11, 2021

@jakobandersen Oops... I missed your comment. I just posted comments to #9023. And I'll review it again in a few days. Please wait for a while. I'd like to merge it to the 4.0.0 release. Let's go forward :-)

@felix-hilden
Copy link

I tried to collect the points about pinning Docutils to the issue linked above. Hopefully it is a good enough place to continue the discussion.

@ericholscher
Copy link
Contributor

If it's the same as @ericholscher said, we have to discuss how to do it (about the workflow).

Thanks for following up on this. I agree that moving forward here to discuss implementation of a testing process is the best use of our time. It sounds like we have #9088 for discussing that in depth (thanks @felix-hilden), so I won't discuss it more here.

Note: About version pinning, it seems agreed now. At least, nobody objects to introduce it now.

This is great to hear @tk0miya -- thanks for talking through this with us. I will think a bit more in depth about the next steps here and do a PR for it. I agree that pinning pygments is probably good also, to reduce unexpected breakage. If we have a good process for testing changes, we want to make sure we have a development step to "ship" those new changes. I don't think we can keep track of dependencies of dependencies that might cause output changes, so there's also some discussion needed here about what additionally needs to be pinned.

I think we should move the pinning discussion into another thread as well, so folks can get back to discussing 4.0 release features :) I created #9091 to discuss that topic in depth.

@pradyunsg
Copy link
Contributor

pradyunsg commented Apr 13, 2021

Requesting to pin this for visibility, so that users doing beta testing downstream can find this "issue" more easily.

(this is something that pip does, and I've received feedback that it's very useful for folks trying to keep track of the discussion)

@tk0miya
Copy link
Member Author

tk0miya commented Apr 13, 2021

4.0.0b1 depends on docutils>=0.14,<0.17. I think it's already pinned. Is there anything to do more additionally? I don't understand what "visibility" means.

@pradyunsg
Copy link
Contributor

Ah, I meant pinning the issue; which is a Github feature. Sorry for the confusion! 😅

@ewjoachim
Copy link
Contributor

I believe @pradyunsg is requesting if an admin can click on this "Pin issue" button (👇) which would be located in the right sidebar on this issue page
Capture d’écran 2021-04-17 à 16 32 19

This would ensure the issue appears at the top of the issue list, make it more visible and reachable.

@tk0miya tk0miya pinned this issue Apr 17, 2021
@tk0miya
Copy link
Member Author

tk0miya commented Apr 17, 2021

Done it.

@gmilde
Copy link

gmilde commented Apr 19, 2021

From now on, the 4.0.x branch is feature freezed. Please let us know
if you still have new features for 4.0.0.

I suggest to rise the Docutils dependency to < 0.18.

Motivation:

There are three known issues with Docutils 0.17:

a) import error for docutils.writers.latex2e with locale-encoding == "ascii"
in Python 3.5 and 3.6.

b) AttributeError because of missing document.settings when parsing included
rST parts with the recommonmark parser.

c) backwards-incompatible changes to HTML output of the html5_polyglot writer.

Issues a) and b) are fixed in Docutils 0.17.1 (released 17 Apr 2021).

Issue c) is no bug for a new "major" release, so 4.0 is the best
chance to get bug fixes and improvements from Docutils 0.17.x in Sphinx fast.

If additional issues arise, these will be handled in a Docutils 0.17.2 bugfix release.

@ericholscher
Copy link
Contributor

If we can confirm that Sphinx and alabaster are working well with 0.17, I'd be 👍 on pinning to docutils<0.18. We can add alabaster to the work in #9088, and confirm it there prior to release.

@tk0miya
Copy link
Member Author

tk0miya commented Apr 24, 2021

I'm perfectly confused by the pinning of docutils. So I stopped releasing for a while. refs: #9088

@astrojuanlu
Copy link
Contributor

astrojuanlu commented Apr 28, 2021

@tk0miya sorry it took us a few days to finally get to this. @humitos and I have just validated that Sphinx with alabaster looks good with Sphinx 4.0 beta and docutils 0.17.

The only noticeable visual difference I observed, after comparing both versions side to side, are in emphasized code lines (baseline, test).

I get the impression that alabaster is not maintained anymore (last commit is from January 2020 and says "Last ever LICENSE copyright update"), therefore I don't think it's worth trying to make a new release of alabaster fixing this small visual difference.

In conclusion: in line with the conditions we agreed here and in #9088, my understanding is that Sphinx 4.0 can pin docutils<0.18, and allow 0.17.

@tk0miya
Copy link
Member Author

tk0miya commented Apr 29, 2021

Now I just released the 4.0.0b2 package. And I posted announce to sphinx-users, sphinx-dev and python-announce-list.
https://pypi.org/project/Sphinx/4.0.0b2/

I'll wait for reactions from users in a week. So the final release will be shipped on 8th May.

Thank you for your support all :-)

@pradyunsg
Copy link
Contributor

Thanks @tk0miya and I'm glad you are feeling better! ^.^

@tk0miya
Copy link
Member Author

tk0miya commented Apr 29, 2021

The only noticeable visual difference I observed, after comparing both versions side to side, are in emphasized code lines (baseline, test).

I think it's not related to the themes. It comes from a change in #7942.

@ericholscher
Copy link
Contributor

@tk0miya I think we're good to release 4.0 on 8th May 🎉 Thanks for working with us here to minimize impacts for users, and @astrojuanlu, @humitos, @pradyunsg, and others for jumping in to help test things.

Hopefully we can make this process smoother in the future by thinking more about how to pin dependencies (#9091), and building on the work we've done here to test releases of major dependencies (#9088). I'm excited about the collaboration here, and hope we can build on it for future releases.

yuhan added a commit to dagster-io/dagster that referenced this issue May 7, 2021
Summary:
sphinx 4.0 release got delayed bc of sphinx-doc/sphinx#9088
maybe we should spend some time upgrading it to 4.0 once it's released and resolve deps on our end all at once (e.g. pin whats needed) -- (may 8th according to sphinx-doc/sphinx#9056)

Test Plan: manually re-indexed search so api doc shows up

Reviewers: sashank

Reviewed By: sashank

Differential Revision: https://dagster.phacility.com/D7785
@tk0miya
Copy link
Member Author

tk0miya commented May 8, 2021

It seems no issues are reported since beta2. So I'll do releasing in tomorrow at noon in JST (about 10-12hrs later).

@tk0miya
Copy link
Member Author

tk0miya commented May 9, 2021

From now on, I start releasing!

@tk0miya
Copy link
Member Author

tk0miya commented May 9, 2021

Done. Thank you for all!

@tk0miya tk0miya closed this as completed May 9, 2021
@tk0miya tk0miya unpinned this issue May 9, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.