-
Notifications
You must be signed in to change notification settings - Fork 82
Update the Backward Compatibility Service Level Agreement (SLA) #35
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
Conversation
[ghstack-poisoned]
|
|
||
|
|
||
|
|
||
| * **OSS** — “stable” features will be deprecated for one release before a BC-breaking change is made. [PyTorch OSS BC-breaking policy](https://pytorch.org/docs/master/) | ||
| * **FB Internal** — we will not break a serialized torchscript program running in production at Facebook (to be replaced with a more generic SLA) | ||
| * PyTorch SLA will ensure that models developed using a cerntain version will be supported for *six months* from the version release date. |
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.
Is 6 months better or 180 days?
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 this is a bit more complex: we had discussed 1 release <= SLA <= 2 releases
So I think the wording we're looking for is along the lines of:
Socialize the 2-release (or 180 days since the BC-breaking change is made, whichever is later) SLA
| * PyTorch SLA will ensure that models developed using a cerntain version will be supported for *six months* from the version release date. | |
| * PyTorch SLA will ensure that models developed using a certain version and developed with non-deprecated APIs, will be runnable (with a slight performance regression allowed) for *up to one more release or 180 days* (from the version release date that introduced the BC-breaking change), whichever is later. |
Maybe it would be worth adding a couple of examples for the version and time based compatibility windows.
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.
Shouldn't we have a sub-section at the end of the proposal section that describes the new SLA? Rather than modifying the "History" section
Good catch! Let me move to the proposal section and update the wording. |
…(SLA)" We are reaching to a consensus to an SLA window (6 months) for both mobile and server, both internal and OSS. Update it accordingly in this RFC. [ghstack-poisoned]
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.
LGTM!
|
Thanks @iseeyuan Should we also call out as a goal/outcome that moving forward we're not having a difference between internal and OSS guarantees since they would be moving under the same SLA? Also, update the Facebook / FB references :-) |
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.
Looks good, aside from the point I raised on internal vs oss
Sounds good! Will call out the outcome, and update "Facebook". Thanks! |
…(SLA)" We are reaching to a consensus to an SLA window (6 months) for both mobile and server, both internal and OSS. Update it accordingly in this RFC. [ghstack-poisoned]
Stack from ghstack:
We are reaching to a consensus to an SLA window (6 months) for both mobile and server, both internal and OSS. Update it accordingly in this RFC.