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

add changelog for message spec #525

Merged
merged 3 commits into from
Dec 23, 2021
Merged

Conversation

minrk
Copy link
Member

@minrk minrk commented Feb 27, 2020

As requested in #520

Changelog goes back to 5.0 (inclusive), when we started tracking these things well and third-party implementations really got going.

Marked as draft because I'm not sure this is the right way to do it. The changelog info is entirely redundant with the version changed/added/deprecated notes (that's where I got the changes), so it means every time we document a change, we must do it twice.

Since Sphinx is fancy about roles, maybe there's a better automated way to display this information twice? Or maybe we should replace the local-to-the-message change notes with the changelog? I'm not sure. For me, the version changed notes near the messages that have changed seems preferable, but as brought up in #520 it's not efficient for a Kernel author who implements protocol 5.0 and asks "what do I need to change to support 5.4?" which is currently to search the doc for "New in" and "changed".

back to 5.0, when we started tracking these things
Copy link
Contributor

@MSeal MSeal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's fine to have the information replicated somewhat. We could do doc linking from one to the other though that can get tedious to write correctly, or just leave a note at the top of both docs that the other one exists? Just so long as the release instructions are updated to clearly specify what's expected and how to do it (I added a RELEASING.md file with 6.0 copied and modified from other jupyter projects)

@willingc
Copy link
Member

@minrk Should we merge this as is?

@blink1073
Copy link
Contributor

I agree with @willingc, I think this can merge as-is for the upcoming 7.0 release

@rgbkrk rgbkrk marked this pull request as ready for review December 23, 2021 18:36
docs/messaging.rst Outdated Show resolved Hide resolved
docs/messaging.rst Outdated Show resolved Hide resolved
willingc and others added 2 commits December 23, 2021 12:17
Co-authored-by: David Brochart <david.brochart@gmail.com>
Co-authored-by: David Brochart <david.brochart@gmail.com>
@willingc
Copy link
Member

@davidbrochart If this looks good to you after CI, please 🚢

@davidbrochart davidbrochart merged commit 3082366 into jupyter:main Dec 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants