I don't think that's it's quite true to say '1.major.minor' is our de facto scheme. Once again, I think many of us have always viewed it as '1.long-term-support.bugfix'.
-- Christopher L Tubbs II http://gravatar.com/ctubbsii On Thu, Apr 3, 2014 at 3:39 PM, Bill Havanki <[email protected]> wrote: > 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
