Corranrogue9/netsupportpolicy #3016
Conversation
| 3. removing support for a .NET version is a breaking change (and therefore requires a major version increment) | ||
| 4. adding support for a .NET version is not a breaking change | ||
| 5. ODL major versions are support for at least 1 year after release (TODO this claim was made in the last meeting, but i can't find in the existing doc) | ||
|
|
There was a problem hiding this comment.
| 6. Any time .NET releases a new GA version, we have a GA version of OData that has been tested to work with that version of .NET | |
| 7. Any time .NET releases a new beta version, we have a beta or GA version of OData that has been tested to work with that beta version within 3 months |
There was a problem hiding this comment.
we need to also make sure that we know (for ourselves) that breaking chjanges are the only way to do some things
There was a problem hiding this comment.
maybe we start with only .NET LTS releases to start with
| 1. How do we communicate the lifecycle moves for each ODL major version? (from John) | ||
| 1. My proposal is to let the nuget release notes do this for us. | ||
| 2. How do we want to handle testing of .NET release candidates? (from many folks on the team) | ||
| 1. My proposal is to test .NET support after the official .NET release, giving a 3 month runway. |
There was a problem hiding this comment.
I think that's too late. I think we have to test with the beta versions of .NET and should have at least a beta version that is verified to work with the .NET release when the .NET release ships, if not sim-ship a GA version of ODL. I'm pretty sure that's what EF does.
There was a problem hiding this comment.
For your information, below is the release cycle for .NET 8:
There was a problem hiding this comment.
we will be part of a beta program instead of being addressed post release; i need to move these dates on the visio file
| 2. How do we want to handle testing of .NET release candidates? (from many folks on the team) | ||
| 1. My proposal is to test .NET support after the official .NET release, giving a 3 month runway. | ||
| 2. Mike had feedback to use ODL beta releases, and had this comment: https://teams.microsoft.com/l/message/19:meeting_NWViNmQzN2ItMmQ0Mi00OGFmLWIxMzktZGVhY2EwMWMyMzBm@thread.v2/1720547775436?context=%7B%22contextType%22%3A%22chat%22%7D | ||
| > There should never be a pre-release version of .NET that does not have OData support (either release or, at minimum, beta). Customers should never be prohibited from moving to any supported or pre-release version of .NET because of lack of OData support. |
There was a problem hiding this comment.
This hsould be our internal goal; we should see if .NET has a beta release cadence; we may want to just establish our own cadence anyway
| 1. My proposal is to let the nuget release notes do this for us. | ||
| 2. How do we want to handle testing of .NET release candidates? (from many folks on the team) | ||
| 1. My proposal is to test .NET support after the official .NET release, giving a 3 month runway. | ||
| 2. Mike had feedback to use ODL beta releases, and had this comment: https://teams.microsoft.com/l/message/19:meeting_NWViNmQzN2ItMmQ0Mi00OGFmLWIxMzktZGVhY2EwMWMyMzBm@thread.v2/1720547775436?context=%7B%22contextType%22%3A%22chat%22%7D |
There was a problem hiding this comment.
Should we establish a regular sync meeting with .net team? we should not, the .net team will give us a heads up whenever it seems applicable from their side
we should reach out to .NET team about this document regarding how to engage earlier in the process and see what might be established with other teams
| 2. .NET support has been tested prior to publishing a version with that .NET support | ||
| 3. removing support for a .NET version is a breaking change (and therefore requires a major version increment) | ||
| 4. adding support for a .NET version is not a breaking change | ||
| 5. ODL major versions are support for at least 1 year after release (TODO this claim was made in the last meeting, but i can't find in the existing doc) |
There was a problem hiding this comment.
| 5. ODL major versions are support for at least 1 year after release (TODO this claim was made in the last meeting, but i can't find in the existing doc) | |
| 5. ODL end of life will be communicated at least 1 year prior to the EOL release (this is a broader microsoft policy) | |
| 2. Mike had feedback to use ODL beta releases, and had this comment: https://teams.microsoft.com/l/message/19:meeting_NWViNmQzN2ItMmQ0Mi00OGFmLWIxMzktZGVhY2EwMWMyMzBm@thread.v2/1720547775436?context=%7B%22contextType%22%3A%22chat%22%7D | ||
| > There should never be a pre-release version of .NET that does not have OData support (either release or, at minimum, beta). Customers should never be prohibited from moving to any supported or pre-release version of .NET because of lack of OData support. | ||
| 4. Mike had this comment in the previous meeting: https://teams.microsoft.com/l/message/19:meeting_NWViNmQzN2ItMmQ0Mi00OGFmLWIxMzktZGVhY2EwMWMyMzBm@thread.v2/1720547233614?context=%7B%22contextType%22%3A%22chat%22%7D | ||
| > Even if the versioning system does not require that we limit ourselves to only doing breaking change releases during LTS releases, in practice I think we should try to align breaking change releases with the LTS releases. |
There was a problem hiding this comment.
this is also an internal goal
- we haven't done many breaking changes
- there is churn for customers, and many of our customers don't have much code churn on their end and so they are less lilely to desire taking fixes
i need to come with an example of a breaking change release that is outside of the .NET cadence
There was a problem hiding this comment.
we maybe want to do an ODL LTS so that customers can take new .NET versions without ODL breaking changes?
Issues
This pull request fixes #xxx.
Description
Briefly describe the changes of this pull request.
Checklist (Uncheck if it is not completed)
Additional work necessary
If documentation update is needed, please add "Docs Needed" label to the issue and provide details about the required document change in the issue.