Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Discussion: package versioning, naming, and target framework choices

Aperta
  • Qualcosa non va?
#270 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
csharp
Ambito
build-system, release

Direzione di ricerca

Inizia esaminando issue #269, l'attuale processo di rilascio dei pacchetti del repository e la relativa configurazione dei framework di destinazione netstandard2.0/netstandard2.1. Il lavoro si considera completato quando sarà stata raggiunta e documentata una decisione sul versionamento delle dipendenze, sulla granularità dei rilasci, sui numeri di versione dei pacchetti e sulla policy per l'aggiunta o la rimozione dei framework di destinazione.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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?

Lingua principale
C#
Stelle
334
Fork
88
Merge medio
3m
PR unite (30g)
1

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di cloudevents/sdk-csharp

Tutte le issue di cloudevents/sdk-csharp

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.