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

Document the versioning scheme in the README: 2.0.x (stable) vs 3.0.0-preview, stale GitHub Releases, and v10/v11 tags

Abierto
#2,813 2 comentarios 13 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
55/100
Tipo de issue
Documentación
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
csharp

Línea de trabajo

Comienza con el README del repositorio y el readme del paquete NuGet, y luego verifica las afirmaciones propuestas sobre el versionado frente a dotnet/dotnet VMR, las versiones de NuGet, GitHub Releases y las etiquetas v10.x/v11.x mencionadas. Confirma las ramas de release relevantes y los hilos anteriores (#1251, #2500, #2576) antes de documentar las versiones estables frente a las de preview, el historial de releases y el significado de las etiquetas; se considera terminado cuando la guía sea correcta y coherente en ambos readmes.

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

Descripción

As a consumer it's currently very hard to reason about which version to use and what changed between versions, because the four places I'd look all disagree:

  • NuGet shows 2.0.8 (latest stable) and 3.0.0-preview.4.*.
  • GitHub Releases is frozen — newest entry is v2.0.2 (Jan 2026); 2.0.3–2.0.8 and all 3.0.0 previews shipped with no release and no notes.
  • Git tags carry SDK-band versions: the same commit c7b5e07c is tagged v2.0.1, v2.0.2, v2.0.3, and v10.0.4/v10.0.5/v10.0.104/v10.0.105; 702b2bbd is tagged v11.0.0/v11.0.100. Meanwhile NuGet 2.0.4/2.0.5/2.0.6 have no tags at all.
  • There's no curated CHANGELOG.

My understanding (please correct): since the source moved into the dotnet/dotnet VMR around 2.0.0-beta6, releases are produced by the central .NET build, the git tags follow .NET SDK bands rather than the package version, and GitHub Releases is no longer the source of truth. If that's right, it would help enormously to state it in the README so people stop re-deriving it.

Ask: add a short "Versioning" section to the README (and ideally the NuGet package readme) answering:

  1. Which version do I use? (2.0.x = stable; what's 3.0.0-preview?)
  2. Why is GitHub Releases stale, and what should I look at instead for a changelog?
  3. What are the v10.x/v11.x tags and can I ignore them?

Suggested starting text (happy to open a PR once the facts are confirmed):

## Versioning

`System.CommandLine` is built and released as part of the .NET product (the
dotnet/dotnet VMR); this repo is a mirror. Use **NuGet** as the source of truth:

- **`2.0.x`** — current stable line (ships with .NET 10). Recommended for production.
- **`3.0.0-preview.x`** — in-development line (.NET 11).

GitHub Releases and the `v10.x`/`v11.x` git tags reflect the .NET build/SDK
versioning, not the NuGet package version — for change history, compare the
relevant release branch (`release/10.0` for 2.0.x, `main` for 3.0) on GitHub.

Related prior threads: #1251, #2500, #2576.

Lenguaje dominante
C#
Estrellas
3.7k
Forks
436
Merge medio
6 h 27 min
PR fusionados (30 d)
2

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 dotnet/command-line-api

Todos los issues de dotnet/command-line-api

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.