I agree with Christopher in principle, but I share Sean's concern about the versioning situation. Right now, the *de facto* versioning scheme is 1.major.minor. We should just adopt semantic versioning (or similar) and then enforce bugs-only for bugfix releases. This gives us the room we need.
For reference: semver.org On Thu, Apr 3, 2014 at 3:24 PM, Sean Busbey <[email protected]>wrote: > -1 > > Until we have a full discussion on compatibility and what we're going to > mean for version numbers, this is counter productive to our > volunteer-driven CtR process. That some of us choose to focus our resources > on more recent major versions is irrelevant. > > Right now, we conflate minor and bugfix versions. This change would mean > instead conflating our major and minor versions. That's going to make it > harder for people to upgrade for compatible improvements because the > inclusion of the major changes will be disruptive. > > We need to have the compatibility and versioning discussion. This band aid > won't help. > > > On Thu, Apr 3, 2014 at 2:16 PM, John Vines <[email protected]> wrote: > > > +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 > > > > > > -- // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
