What Dave said :D With "strictness", all non-bugfix changes are reserved for a "long-term-support" increment. Yet that may not happen often by its very definition, which eliminates the ability to generate rapid releases.
Accumulo 2.0.0, baby. On Thu, Apr 3, 2014 at 6:59 PM, <[email protected]> wrote: > > I like the idea of what semver defines (and provides in maven plugins). > I don't think we are following this methodology today. I think people > have a tendency to want to backport or add features to patch releases > because of the long running release cycles (I know I have). If we could get > the testing/release cycle to be faster, then we could put out more minor > and patch releases and not have long running releases. The other problem > is users that are stuck on a particular version. They want the patches, but > not the api changes. If we could tell our consumers that 1.7 will be client > api compatible with 1.6, then users will likely upgrade faster and we will > have less pressure to backport features to a minor/patch release. > > +1 to the main idea of this thread, but I think "bug only" strictness for > patch releases will be the positive side effect of faster testing/releases > and adopting some specification like semver. > > - Dave > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Christopher > Sent: Thursday, April 03, 2014 3:45 PM > To: Accumulo Dev List > Subject: Re: [DISCUSS] Bugs-only strictness for bugfix releases > > 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 > > -- // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
