dashorst opened a new issue, #1700: URL: https://github.com/apache/wicket/issues/1700
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? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
