+1
On Thu, Apr 3, 2014 at 2:15 PM, Christopher <[email protected]> wrote: > JIRA JQL: > 'project = ACCUMULO AND resolution = Unresolved AND type not in > (Sub-task, Bug) AND fixVersion in (1.4.6,1.5.2,1.6.1)' > > There are 32 outstanding issues not marked as "Bugs" planned for > bugfix releases. This seems inappropriate to me. I would prefer to be > very strict about the right-most segment of a version number, by > defining it as "for bugfix releases", and by following the rule: if > the issue doesn't fix a bug, then it doesn't go in a bugfix release. > > This strictness could help us focus on fixing and supporting actual > bugs in previous releases, without being bogged down by non-bugs, it > could help focus improvements in the latest version and encourage more > rapid releases, and give users more reasons to upgrade. It would also > help stabilize previous releases, by avoiding the introduction of new > bugs, which bodes well for long-term support. > > I know we've previously talked about semver and other strict > versioning schemes, but regardless of whether we do any of those other > things, I think this strictness is the very least we could do, and we > could start encouraging this strictness today, with minimal impact. > All it would take is to define the last segment of the versioned > releases as "for bugfix releases", regardless of defining the rest of > the version number (which can be discussed separately, and this is a > subset of most any versioning scheme we've discussed already). > > The implication is that some things we've done in the past to > "backport" improvements and features, which didn't address a bug, > would no longer be permitted. Or, at the very least, would have been > highly discouraged, or would have warranted a vote (see next > paragraph). > > As with anything, there may be important exceptions, so perhaps with > this strictness about "bugfix only for bugfix releases", we could > encourage (by convention, if not by policy) calling a vote for > non-bugfix changes, and rely on the veto for enforcement if a > non-bugfix was applied to a bugfix version. If we agree to this > strictness as a community, knowing a particular change is likely to > result in a veto can be a big help in discouraging violations. > > As a final note, I should mention that there are at least a few of us > who have been thinking about this last segment of the version as > "bugfix only" anyways, if only informally. The lack of > formalization/strictness about this, though, has permitted some things > in the past that are probably not the best ideas in terms of stability > and long-term support of previous release lines. Hopefully, by > adopting this strictness as a community, instead of just informally in > a few of our heads, we can all get on the same page, and it will make > the project better overall. > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii >
