12.1-STABLE is missing in bugzilla's Version choices when creating a PR related to the base system. Or maybe the multiple 11.x-STABLE and 12.x-STABLE entries should in fact be single 11-STABLE and 12-STABLE ? "svnlite info" and "uname -r" are somehow inconsistent in that regard.
At the moment the defacto process is to have a -STABLE version entry for every X.Y version, so I've added a 12.1-STABLE option accordingly Longer term, the questions needs to be asked: - To what extent are people reporting or triaging issues (correctly/accurately) on a per X.y_STABLE basis. ie: How useful/valuable are these X.Y-STABLE versions for bug reporting purposes, in fact/practice. - To what extent to we (as a project) want, or need to distinguish between, and support, X.Y-stable versions for bug reporting purposes, given our almost exclusive workflow of: - Commit to head - MFH to stable/X Noting/considering also that: The process/tracking of merges is not complete or consistent in bugzilla, or via commit log messages. Direct to releng/X.Y branches is practically non existent, and even where it exists, is not in almost all circumstances tracked via issues in Bugzilla (though this would be nice) The version numbering as displayed via `uname` (and other places) is not the most intuitive for most users, particularly with regard to the X.*Y* (major.minor) notation within a stable/X (major) branch (ie/also knows as: why doesn't it just show 12-STABLE) Yes we use it to denote what the *next* X.Y version cut from that major branch will be, but that doesn't resolve the question with regard to how and to what extent we need to have those granular versions bug *bug reporting* and *triage* purposes, nor whether we're actually using them for those purposes at the moment, traded off against the greater complexity for users reporting bugs from showing these versions. Lastly, while on one hand its useful to know exactly what (granular) version an issue is reproducible in, it is also the case that !RELEASE versions are, effectively, and communicated as such, "unsupported". Personally (with bugmeister hat one), at this point, given our processes, coupled with the desire and aim to make bugzilla reporting as easy as possible, I take the view that "12-STABLE" (or "STABLE/12", reflecting the branch) without minor versions is enough to identify the branch the user is on, and the branch within which a fix will be committed/merged
(In reply to Kubilay Kocak from comment #1) Should we treat this as a duplicate of (superseded by) 267310? See also: <https://wiki.freebsd.org/Bugzilla> ▶ problems and ideas.
(In reply to Graham Perrin from comment #2) > … duplicate of (superseded by) 267310? … … or 262494? Bug 262494 comment 2 in particular.
Committed as part of 267310.
(In reply to Mark Linimon from comment #4) Thanks! (I became confused in 267310, sorry.)