-
Notifications
You must be signed in to change notification settings - Fork 287
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
Conversation
back to 5.0, when we started tracking these things
There was a problem hiding this 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)
@minrk Should we merge this as is? |
I agree with @willingc, I think this can merge as-is for the upcoming 7.0 release |
Co-authored-by: David Brochart <david.brochart@gmail.com>
Co-authored-by: David Brochart <david.brochart@gmail.com>
@davidbrochart If this looks good to you after CI, please 🚢 |
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".