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

docs: versioned docs per release (/vX.Y/, /latest/, /dev/)

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

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Documentación
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
c, shell
Área
build-system, documentation, release

Línea de trabajo

The docs are in the docs/ directory; the release workflow and build system need changes to publish per-version docs. Start by examining the existing documentation build script (likely a shell script or Makefile) and the GitHub Actions workflow for releases. Understand how the current site is deployed. The goal is to create a structure where each release tag's docs are published under /vX.Y/, /latest/ points to the newest release, and main's docs go to /dev/. This involves versioning the docs, adding version markers to pages, and ensuring old versions remain accessible.

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

Descripción

area:docs help wanted kind:decision

Problem. The docs site is built from main only. A user on the latest release (v0.43.0) reads docs for whatever is on main, which can describe features, flags or semantics their binary does not have.

What mature languages do. docs.python.org/3.12/, docs.rs//, and pkg.go.dev's version tab all serve each release's docs, with a stable "latest".

Bar.

  1. Each release tag's docs/ is published under /v<major.minor>/, and /latest/ points at the newest release. main's docs are published under /dev/ (or equivalent), clearly labelled unreleased.
  2. Every page carries a visible version marker, with a link to the same page in other versions where it exists.
  3. The release-cut workflow publishes the new version's docs, and the playground is built from the same tag.
  4. Old versions keep working after a new release (a link check against at least the previous version).

Ranked #5 of the docs follow-ups (2026-09-22 comparison with other languages). Most work; matters most once there are outside users.

Done when

  • Decision recorded in a comment here: versioned docs now (/v<major.minor>/ per release tag, /latest/, /dev/ for main), defer until the first outside consumer (the v1 trigger, #1286), or main-only. Name the chosen option and why.
  • If adopted: the Pages site serves /latest/ (newest release tag's docs/), /dev/ (main, labelled unreleased on every page) and /v<major.minor>/ for at least the current and previous release.
  • If adopted: every page shows its version, with a link to the same page in the other published versions where that page exists.
  • If adopted: release.yml publishes the new version's docs and builds the playground from the same tag, and a link check against the previous version's tree runs after publishing and passes.
  • If rejected or deferred: close (or relabel) with the reason and the trigger that reopens it.
Lenguaje dominante
C
Estrellas
3
Forks
7
Merge medio
4 h 7 min
PR fusionados (30 d)
112

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

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 InauguralSystems/EigenScript

Todos los issues de InauguralSystems/EigenScript

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.