accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [DISCUSS] Bugs-only strictness for bugfix releases
Date Mon, 07 Apr 2014 14:40:19 GMT
On Thu, Apr 3, 2014 at 3:44 PM, Christopher <ctubbsii@apache.org> wrote:

> 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'.
>

Thats how I have thought of it.  It the major version that was a mess
because we used to add new APIs and drop deprecated APIs when incrementing
the major version.

No matter what we decide for future versions, the 1.4.X, 1.5.Y, and 1.6.Z
lines will still exist and be in use.  Why not try to set some goals for
them?  I would like to see the following things for those lines.

 * 1.4.(X+1), 1.5.(Y+1), and 1.6.(Z+1) are more stable than the X,Y,and Z
versions.  Known critical bugs were fixed and we try not to introduce new
critical bugs.
 * 1.4.(X+1), 1.5.(Y+1), and 1.6.(Z+1) will run any software that ran on
the X,Y,and Z versions.
 * I would like to see the reverse of the above also, where software
written on X+1, Y+1, and Z+1 versions will run on X,Y,and Z versions.  I
think this makes using bug fix release much less confusing.


> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Thu, Apr 3, 2014 at 3:39 PM, Bill Havanki <bhavanki@clouderagovt.com>
> 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 <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