accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Havanki <bhava...@clouderagovt.com>
Subject Re: [DISCUSS] Bugs-only strictness for bugfix releases
Date Thu, 03 Apr 2014 19:39:25 GMT
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 <busbey+lists@cloudera.com>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 <vines@apache.org> wrote:
>
> > +1
> >
> >
> > On Thu, Apr 3, 2014 at 2:15 PM, Christopher <ctubbsii@apache.org> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message