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

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

Aperta
  • Qualcosa non va?
#1,700 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
github, java
Ambito
backend-api-design

Direzione di ricerca

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.

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

Descrizione

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?
Lingua principale
Java
Stelle
800
Fork
421
Merge medio
22h 12m
PR unite (30g)
47

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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

Tutte le issue di apache/wicket

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.