[release/8.0.1xx] Validate this extension methods and member types in APICompat #34999
Conversation
There was a problem hiding this comment.
Looks good to me, and I support getting this in for RC2. We should put this out for Tactics approval to at least ensure everyone's informed this is coming.
@ViktorHofer Aside from Tactics visibility, what breaking change notifications do we typically broadcast for new APICompat validations?
@carlossanlop let me know that they talked about this today in Tactics and that M2 approval is sufficient. I also sent out a mail to Tactics earlier today. Please let me know if we should do anything more.
Good point. APICompat / PackageValidation has received a couple of new features that are - by nature - breaking. I will file one breaking change issue for all the new features. |
|
@MrJul again thanks for reporting #34864. Just wanted to let you know that this PR backported the change that closes your issue into .NET 8 RC2 and newer. RC2 will be available in October. If you want to depend on these changes already today you have the following options:
... otherwise, wait for the .NET 8 RC2 release. |
|
Thanks for the solving the issue quickly and letting me know, much appreciated :) |
Backport of d0a4bf1 and 6fad359
Customer Impact
Customers use APICompat / PackageValidation to validate their public API changes. While we already have a large set of compatibility rules, we were missing two major cases: a) member type validation (i.e.
public string a->public bool awhich is a breaking change) and b) the "this" modifier for extension methods (public static void ExtMethod(this string a)->public static void ExtMethod(string a)which also is a breaking change).By taking this change, we increase our customer's confidence in our shipping tooling by validating these two common scenarios. This was reported by a customer and by dotnet/runtime folks.
Testing
Tests were added for both scenarios and they are running in CI. I also tested the changes in dotnet/runtime manually and its main branch already uses an APICompat version with these changes.
Risk
Low to Medium. Existing scenarios are validated by tests. In general, new validation in APICompat is considered a breaking change as customers need to react to those. But that's exactly the reason why customers use APICompat as they want their API changes to be validated and APICompat to error out for incompatible changes.