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.

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

Corranrogue9/netsupportpolicy #3016

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

Conversation

corranrogue9
Copy link
Contributor

Issues

This pull request fixes #xxx.

Description

Briefly describe the changes of this pull request.

Checklist (Uncheck if it is not completed)

  • Test cases added
  • Build and test with one-click build and test script passed

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.

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

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. 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.
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

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

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)

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.
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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants