Breaking changes for v7

[nwithan8]

Description

• Remove previously-marked obsolete classes, properties and functions
  • Update unit tests accordingly
• Update examples submodule
  • Re-record cassettes, update fixtures as needed
• Prepare changelog and upgrade guide for v7

Testing

Pull Request Type

Please select the option(s) that are relevant to this PR.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Improvement (fixing a typo, updating readme, renaming a variable name, etc)

[Justintime50]

Do we even need a breaking change at the moment? This doesn't really add anything (eg: why would a user want to upgrade) vs just removing obsolete functions which could occur later when we have another reason to release a breaking change.

Can we instead do a normal feature release to add those couple things you needed?

[nwithan8]

Do we even need a breaking change at the moment? This doesn't really add anything (eg: why would a user want to upgrade) vs just removing obsolete functions which could occur later when we have another reason to release a breaking change.

Can we instead do a normal feature release to add those couple things you needed?

We did a breaking change last time we removed deprecated code and altered supported .NET versions: https://github.com/EasyPost/easypost-csharp/releases/tag/v6.0.0-rc1

[Justintime50]

We did a breaking change last time we removed deprecated code and altered supported .NET versions: https://github.com/EasyPost/easypost-csharp/releases/tag/v6.0.0-rc1

Sorry, my question isn't do we need a breaking release for these changes, it's do we need to do any of this now? Can we wait until there is something substantial to include which would be a motivating reason to upgrade? Cleaning up tech debt typically isn't super exciting to end-users who would then choose not to upgrade if not accompanied by other features.

[nwithan8]

We did a breaking change last time we removed deprecated code and altered supported .NET versions: v6.0.0-rc1 (release)

Sorry, my question isn't do we need a breaking release for these changes, it's do we need to do any of this now? Can we wait until there is something substantial to include which would be a motivating reason to upgrade? Cleaning up tech debt typically isn't super exciting to end-users who would then choose not to upgrade if not accompanied by other features.

No, there is nothing in this specific PR that is immediately needed.

A separate already-merged PR that changed supported .NET versions should be released given that .NET 9.0 is now officially released, and as previously noted, a major version bump was used to change the .NET versions last time (although that also included code removal; we can discuss using instead a minor release to alter .NET versions).

[Justintime50]

Shelving for now due to prioritization