Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#1,700 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
github, java
Lĩnh vực
backend-api-design

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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?
Ngôn ngữ chính
Java
Star
800
Fork
421
Merge trung bình
1 ngày 20 phút
Pull request đã merge (30 ngày)
49

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/wicket

Tất cả issue của apache/wicket

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.