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

Decide how issues record affected version, regression, target branches and fix version

Abierto
  • ¿Algo no está bien?
#1,700 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
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
github, java
Área
backend-api-design

Línea de trabajo

Start with the proposal, constraints, and open questions in this issue, then read build-changelog.sh and AGENTS.md to understand the current release note and commit conventions. The work is to decide and consistently apply a convention for affected versions, regressions, target branches, and release notes; done means the open questions are resolved and the chosen convention is reflected in the project workflow.

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

Descripción

Since issues moved from Jira to GitHub, nothing records what Jira's fields used to: which version a bug affects, whether it is a regression, which release lines a fix has to go to, and which release it shipped in. Jira had Affects Version/s and Fix Version/s, both multi-valued, and the release notes were generated from the latter. On GitHub the repository has no milestones and no labels for versions, branches or issue types, so:

  • a reporter's version is free text somewhere in the issue, if it is there at all;
  • the decision which maintenance lines get a fix is not written down, and once the master fix closes the issue there is no way to see whether the backports happened;
  • build-changelog.sh has nothing to build the release notes from (#1699).

We should decide on a convention and apply it consistently.

What other projects do

None of them has a structured affects-version. The common pattern is a regression label with the affected version in the issue text, usually collected through an issue form.

Project Regression Fix version across branches
Spring Boot type: regression one issue per branch, each with its own milestone; status: back-port / status: forward-port
Rust regression-from-stable-to-stable, -to-beta, -to-nightly, regression-untriaged –
Kubernetes kind/regression –
Quarkus triage/regression triage/backport-3.20, -3.27, …
Node.js regression per line: backport-requested-v24.x, backport-open-, backport-blocked-, backported-to-
Maven – backport-to-4.0.x, backport-to-3.10.x

GitHub's issue fields (custom fields, GA since July 2026) could hold an "Affects version", but they are defined per organization with a limit of 25. For us that is the apache organization, which makes it an ASF Infra decision for every project rather than ours.

Constraints

  • A milestone cannot be the fix version: an issue has at most one, and a fix cherry-picked down from master ships in up to four releases.
  • Per-release labels (10.9.0, 9.22.0, …) can express that, but someone has to add one per line per release, and a forgotten label silently drops the entry from the changelog.
  • The commits between two rel/wicket-* tags on a branch are an exact record of what shipped. Cherry-picks keep the commit body, so a GitHub issue #N reference follows the fix to every line. Today only 17 of the 327 commits on master since January name an issue that way; most of the rest are PR-numbered squash merges, many from dependabot.
  • The apache organization has issue types enabled: Bug, Feature, Task. An issue has exactly one, independent of branch.

Proposal

  • Affected version: a bug-report issue form with a required "Affected version" field.
  • Regression: a regression label.
  • Target lines: branch labels 8.x, 9.x, 10.x, 11.x, set at triage. Optionally Node's lifecycle (backport-requested-10.x → backported-to-10.x) so the state survives the issue closing.
  • Fix version: not tracked on the issue. build-changelog.sh derives it from the tag range and the GitHub issue #N references, and resolves PR numbers to their linked issues.
  • Grouping in the release notes: the issue type (Bug, Feature, Task).
  • Consistency check: build-changelog.sh warns about a closed issue labelled for a line that has no commit for it in that line's range.
  • Commits: keep naming the issue in the body (GitHub issue #N), as AGENTS.md already asks.

To decide

  • Branch labels alone, or with the backport lifecycle?
  • Do dependency upgrades from dependabot go in the release notes, and under which heading?
  • Do we want a 12.x label before that line exists? (Proposal: no.)
  • Is anyone in favour of per-branch issues with milestones, as Spring Boot does, instead?
Lenguaje dominante
Java
Estrellas
800
Forks
421
Merge medio
1 d 20 min
PR fusionados (30 d)
49

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 apache/wicket

Todos los issues de apache/wicket

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.