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

Proposal for dropping .NET Standard #3701

Closed
wants to merge 6 commits into from

Conversation

alanwest
Copy link
Member

Opening this proposal up as a PR for us to discuss. This PR is not meant to be merged. The plan is to post the contents of this PR as an announcement.

@alanwest alanwest requested a review from a team September 28, 2022 01:03

At this time, the frameworks targeted will include at least `net462` and
`net6.0`, but may include others like `net7.0`, when appropriate. As target
frameworks reach end of life, we will remove those targets during a major
Copy link
Member

Choose a reason for hiding this comment

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

major version is something like 2.0 / 3.0?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, that's what I'm proposing 😄.

Copy link
Member

Choose a reason for hiding this comment

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

#2138 historically we only did minor version bump when we dropped framework support (when the fw itself went out-of-support)

Copy link
Member

Choose a reason for hiding this comment

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

I don't have strong opinion on this. I guess either way should work.

If we go down this path, there is a need to be able to communicate/distinguish whether a major version bump is purely because of certain version drop, or because of some API breaks, or a combination of both. For example, a user might be worried about upgrading from 2.0 to 3.0 due to the fear of breaking changes, although what actually happened is just a drop of deprecated runtime version.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, this differs from our prior pattern of practice, and I'm suggesting we reconsider our practice for the future. As mentioned in dotnet/announcements#190

Dropping a framework from a package is a source breaking change.

I think a major version number is the correct tool to communicate this to users clearly. It aligns with the .NET Runtime team's versioning of DiagnosticSource in regards to dropping supported frameworks.

That said, there certainly are other examples of library authors dropping frameworks with minor version releases of their libraries. Though, I do not think a minor version bump communicates very clearly whether the drop in support was intentional or not.

I'd be very interested in some official guidance to library authors in this respect. Maybe here https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/versioning. Something like:

✔️ CONSIDER (or DO?) bumping the major version when dropping framework support.

Maybe .NET would consider this overstepping their bound with their guidance, but I'd like to hear their thoughts.

Copy link
Member Author

Choose a reason for hiding this comment

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

it will need to change the current position: a major version bump is NOT going to introduce breaks to the API surface or any telemetry data semantics

Yes, fair. Personally, I think this would be a worthy goal in the long run. So basically adopting option number 2.

In the short run though, I was more considering option number 3. Version 1.x of OTel .NET has served as a learning grounds as OpenTelemetry has matured. We already have a number of things marked Obsolete and we're anticipating some more. I think cleaning these things up in a breaking major release will end up benefitting users in the long run.


Though let me ask a different question. Do we all agree we want to drop .NET Standard targets from our core packages in the future? If so, my primary intent with this announcement is to:

  1. Give end users a very clear notice of our intended plan to drop .NET Standard, and
  2. Some sense of a rough timeline for when we will do this.

Whether this be in a minor or major release is more of a technical detail.

Copy link
Member Author

Choose a reason for hiding this comment

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

In other words, I'm proposing this announcement as our resolution to #3448.

Copy link
Member Author

Choose a reason for hiding this comment

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

#3703 as an alternative resolution to #3448.

Choose a reason for hiding this comment

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

To summarize, I think we have the following options: ...

IMO, option (3) is the best one. I think many people assume minor version number bump = "not a breaking change, may add features, no need to even look at release notes if I don't feel like it." Doing a minor version bump that broke people because it dropped support for the runtime they were using would be unexpected.

For option (2) I'd be careful about promises that you will never make a breaking change, it could become a real straight jacket. I'd suggest something more like you strongly value compatibility and breaking changes should be rare.

Copy link
Member Author

@alanwest alanwest Sep 29, 2022

Choose a reason for hiding this comment

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

Thank you for your guidance @noahfalk!

Doing a minor version bump that broke people because it dropped support for the runtime they were using would be unexpected.

This is the primary reason I'm suggesting changing our practice to a major version bump under this proposal because with the absence of .NET Standard targets, dropping support for a runtime version means users on old frameworks can not upgrade.

Previously, when we dropped net461, netcoreapp3.1, and net5.0 targets we have done it with a minor version bump. Though, in all of these instances, users targeting these frameworks can currently still upgrade as they will fall back to our netstandard2.x targets. It is for this reason I was not as inclined to recommend a major version bump.

@cijothomas @CodeBlanch @utpilla Maybe we chat once more in next week's SIG meeting before choosing between this proposal or #3703? If we're set on dropping .NET Standard, we can also further discuss the topic of major vs. minor version bump.

netstandard.md Outdated Show resolved Hide resolved
netstandard.md Outdated Show resolved Hide resolved
Co-authored-by: Cijo Thomas <[email protected]>
@alanwest
Copy link
Member Author

alanwest commented Oct 4, 2022

Closing this in favor of #3703. Discussed in SIG meeting today to keep .NET Standard targets for now. We can always come back to the decision to remove .NET Standard targets at a later date.

@alanwest alanwest closed this Oct 4, 2022
@alanwest alanwest deleted the alanwest/proposal branch October 13, 2022 19:25
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.

5 participants