-
Notifications
You must be signed in to change notification settings - Fork 556
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
docs: guidelines for public interface management #2108
base: main
Are you sure you want to change the base?
Conversation
These guidelines sets out some approaches for managing our public interface, it presents options for integrating code related to breaking changes into the main branch while still allowing control as to when those changes are released to users. Happy for any suggestions, there may be better options or problems with these options that I'm overlooking.
b6fecd7
to
a474638
Compare
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.
keen to try it out
A colleague of mine (@nikitabarskov) pointed out to me today that google does do what I'm suggesting here [ref], so there is some precedent for this approach. Google has for example I would have gone for |
More precedent/prior art that I found which: This is arguably even more similar to what I'm proposing here. |
Just to re-emphasize why this matters: Every time we break our interface we push a significant cost onto our users, the more it costs them to use RDFLib, the less they like it. There are many ways in which we can batch breaking changes and release it in a coordinated fashion without releasing a new major version every release, and we really should be doing that. Rushing interface changes out to users makes our lives harder and is not that helpful to them either. |
I'm going to clean this up a bit this week, the essence of it will stay the same but I will improve the writing and clarity slightly. If there is no further feedback, I will merge it next weekend. |
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.
👍
As discussed in #2395 I think this is too ambitious, I will make it a draft and likely close it soon. |
Add guidelines on how breaking changes should be approached. The guidelines take a very pragmatic approach with known downsides, but this seems like the best compromise given the current situation. For prior discussion on this point see: - RDFLib#2395 - RDFLib#2108 - RDFLib#1841
Summary of changes
These guidelines sets out some approaches for managing our public
interface, it presents options for integrating code related to breaking
changes into the main branch while still allowing control as to when
those changes are released to users.
Happy for any suggestions, there may be better options or problems with
these options that I'm overlooking.
Checklist
the same change.
so maintainers can fix minor issues and keep your PR up to date.