Discussion: package versioning, naming, and target framework choices

As raised in #269, we would like to take a breaking change in the MQTT package in terms of updating to a new major version. Things like this are going to happen every so often - this isn't a one-off. Let's discuss a few related things at the same time...

Please add comments with your views.

New major version of a dependency

There are at least three options for this:

1. Create a separate package with the new major version dependency. This ends up proliferating the set of packages we publish, but allows users to keep up to date with the SDK without forcing them to potentially fix things due to a new major version of MQTT.
2. Create a new major version of the existing package. This effectively "warns" users of the breakage, but doesn't allow "latest SDK code, older version of MQTT". (Strictly speaking, users could keep the old version of the MQTT package and just update the CloudNative.CloudEvents package, of course...) Note that this is also a change to our existing process of using the same version number for everything.
3. Create a new minor version of the existing package. This violates SemVer, in that it could very easily be a breaking change to update to a new major version of MQTT - after all, there must be a reason why MQTT took a new major version.

Personally I think option 2 makes the most sense in this case, but we should think about what to do if there are frameworks with multiple popular concurrent major versions - at that point, option 1 is attractive.

Release granularity and version numbers

At the moment, we release all packages when we release anything, and everything has the same version number (except things still in beta). Is that what we want to keep doing? If we opt for option 2 of the above, we could potentially keep a similar policy, but keep the minor/patch version consistent across all packages, and allow the major version to vary by package.

Alternatively, we could decide to only release packages when we need to - so a change to (say) the protobuf package only requires the protobuf package to be updated. We might want to periodically re-release all packages if the "core" package has changed, just to make sure users "see" the update even if they've only got a direct dependency on a different package. This approach needs care, to make sure we don't make a change to the core and (say) protobuf, then release only protobuf without its core dependency.

Dropping target frameworks

Over time, we may want to drop frameworks. As a reminder, we currently target netstandard2.0 and netstandard2.1. We may well want to add specific targets (e.g. net6.0) for optimization purposes, where there's a more efficient option on those platforms. Other projects that I'm working on at the moment target net6.0, netstandard2.0 (or netstandard2.1) and net462. If we can avoid targeting .NET Framework directly, that would make me happy :) Readers may want to check out the Google .NET Support Policy, specifically around platforms:

When releasing a new version of a package:

• We support all runtime versions supported by Microsoft at the time of release.
• When releasing a new patch version, the package will support the same set of runtimes as the other patch versions in the same major/minor version.
• When releasing a new minor version, the new version may support fewer runtimes than previous minor versions in the same major version, dropping support for runtimes that have been out of support by Microsoft for a year or more.
• When releasing a new major version, runtimes that were supported in earlier versions of the same package may be dropped if they are no longer supported by Microsoft, even if that support has only recently been dropped.

How would folks feel about a similar policy for this repo?

Start by reviewing issue #269, the repository's current package release process, and its netstandard2.0/netstandard2.1 target framework configuration. Done means reaching and documenting a decision on dependency versioning, release granularity, package version numbers, and the policy for adding or dropping target frameworks.