Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Discussion: package versioning, naming, and target framework choices

Abierto
  • ¿Algo no está bien?
#270 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
csharp
Área
build-system, release

Línea de trabajo

Comienza revisando issue #269, el proceso actual de publicación de paquetes del repositorio y su configuración de los frameworks de destino netstandard2.0/netstandard2.1. Se considera terminado cuando se haya alcanzado y documentado una decisión sobre el versionado de dependencias, la granularidad de las publicaciones, los números de versión de los paquetes y la política para añadir o eliminar frameworks de destino.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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?

Lenguaje dominante
C#
Estrellas
334
Forks
88
Merge medio
3 min
PR fusionados (30 d)
1

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de cloudevents/sdk-csharp

Todos los issues de cloudevents/sdk-csharp

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.