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.

Sign up for GitHub

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

Jump to bottom

Corranrogue9/netsupportpolicy #3016

Draft
wants to merge 3 commits into
base: release-7.x
Choose a base branch
from
Draft

Corranrogue9/netsupportpolicy #3016

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
60cbdb9
adding .net support policy
corranrogue9 Jul 15, 2024
25f4fc7
asdf
corranrogue9 Jul 15, 2024
477ee94
Update netsupportpolicy.md
corranrogue9 Jul 15, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .gitignore
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -64,3 +64,4 @@ test/FunctionalTests/Tests/Data/Northwind/Northwind.csdl2.csdl
# Symbol
*.pdb

*.~vsdx
Binary file added .net support.vsdx
View file
Open in desktop
Binary file not shown.
16 changes: 16 additions & 0 deletions netsupportpolicy.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
.NET support rules:
1. ODL does not support .NET versions that are out-of-support
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)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Suggested 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)
5. ODL end of life will be communicated at least 1 year prior to the EOL release (this is a broader microsoft policy)


Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

we need to also make sure that we know (for ourselves) that breaking chjanges are the only way to do some things

Copy link
Contributor Author

Choose a reason for hiding this comment

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

maybe we start with only .NET LTS releases to start with

open items:
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.
Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Member

Choose a reason for hiding this comment

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

For your information, below is the release cycle for .NET 8:

image

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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. 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
Copy link
Contributor Author

Choose a reason for hiding this comment

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

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

> 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.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

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

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.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

this is also an internal goal

  1. we haven't done many breaking changes
  2. 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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

we maybe want to do an ODL LTS so that customers can take new .NET versions without ODL breaking changes?