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 23:03:39 GMT
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, <dlmarion@comcast.net> 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: ctubbsii@gmail.com [mailto:ctubbsii@gmail.com] 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 <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
>
>


-- 
// Bill Havanki
// Solutions Architect, Cloudera Govt Solutions
// 443.686.9283

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