Ask which release line a bug report is on

[maxisbey]

With both the 2.x stable line and the 1.x maintenance line supported, the bug form's "I confirm that I'm using the latest version" checkbox is ambiguous for a 1.x reporter.

Motivation and Context

Rewords the check as "the newest release of my line" and adds a required Release line dropdown (2.x / 1.x) so triage can see the major at a glance.

How Has This Been Tested?

The form YAML parses and follows the same dropdown schema as v2-feedback.yaml; GitHub only renders issue forms from the default branch, so the live check is after merge.

Breaking Changes

None.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

_{AI Disclaimer}

[cubic-dev-ai]

No issues found across 1 file

_{Re-trigger cubic}

[claude]

LGTM — a straightforward issue-template tweak that aligns the bug form with the two-line (2.x stable / 1.x maintenance) release model.

What was reviewed:

• Validated the modified bug.yaml parses as YAML and the new dropdown block matches the schema pattern already used in v2-feedback.yaml (options + validations.required).
• Checked the reworded checkbox and dropdown wording against the branching model documented in AGENTS.md/RELEASE.md — consistent.
• No code paths touched; GitHub renders issue forms from the default branch, so the only live verification is post-merge, as the description notes.

Extended reasoning...

Overview

This PR modifies a single file, .github/ISSUE_TEMPLATE/bug.yaml. It rewords the "latest version" confirmation checkbox to account for the two supported release lines (2.x stable and 1.x maintenance), and adds a required Release line dropdown with 2.x and 1.x options so triage can see the reporter's major version at a glance. No source code, tests, CI, or dependencies are touched.

Security risks

None. This is a GitHub issue-form template — it affects only the fields shown when a user files a bug report. There is no executable code, no workflow permissions, and no user-input handling beyond GitHub's own form rendering.

Level of scrutiny

Minimal scrutiny is appropriate. The main failure mode for issue-form changes is invalid YAML or an invalid form schema, which would break the bug-report form. I verified the file parses as YAML and that the new dropdown block (options list plus validations.required: true) matches the schema of the existing dropdown in v2-feedback.yaml in the same directory, which is known to render correctly. The block ordering (checkboxes → dropdown → textareas) and ids are unique and well-formed.

Other factors

The bug hunting system found no issues, and the PR timeline has no outstanding reviewer comments. The wording change is consistent with the repository's documented branching model (main = v2 stable, v1.x = maintenance, only critical fixes backported), so the content is accurate as well as syntactically valid. GitHub only renders issue forms from the default branch, so live rendering can only be confirmed post-merge — but the schema match with an existing working template makes the risk negligible.