Proposal for dropping .NET Standard #3701
Conversation
|
|
||
| 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 |
There was a problem hiding this comment.
major version is something like 2.0 / 3.0?
There was a problem hiding this comment.
Yes, that's what I'm proposing 😄.
There was a problem hiding this comment.
#2138 historically we only did minor version bump when we dropped framework support (when the fw itself went out-of-support)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
- Give end users a very clear notice of our intended plan to drop .NET Standard, and
- 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.
There was a problem hiding this comment.
In other words, I'm proposing this announcement as our resolution to #3448.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Co-authored-by: Cijo Thomas <cithomas@microsoft.com>
|
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. |
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.