You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Christopher <ct...@apache.org> on 2014/04/03 20:15:31 UTC
[DISCUSS] Bugs-only strictness for bugfix releases
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
Re: [DISCUSS] Bugs-only strictness for bugfix releases
Posted by Christopher <ct...@apache.org>.
Sean,
CtR is irrelevant. This can be enforced with vetoes, and if we agree
it's generally a bad idea, there's no reason we can't start vetoing
today, under CtR rules. The only thing that changes by coming to a
general agreement on this is perhaps less stigma and animosity for
leveraging vetoes to enforce this (and the ability to use brevity in
justifying a veto, as in "-1: we agreed we'd avoid this" instead of
"-1: this increases the risk of bugs, and has little benefit, and
detracts from current efforts, and ......." every time).
As I tried to point out towards the end, the "we conflate minor and
bugfix versions" is not quite true. Some of us have done that, but
others have been pushing for a long time to be more strict about not
doing this, and have pretty much always viewed that segment of the
versioning scheme as dedicated to bugfixes. In any case, even if it
were completely true that "we conflate..." today, it's irrelevant, as
the point of this email is an attempt to get us to *stop* performing
such conflations, not to acknowledge the past instances of them.
I don't know that this is a bandaid, so much as a subset of the larger
discussion of compatibility and versioning. And, since we generally
*don't* have a well defined API versioning standards, it does make
more sense to conflate "major/minor" rather than "minor/bugfix"...
especially since we've only ever had "minor" releases. I think this is
a much easier thing to agree on than one that discusses a full
versioning scheme when we don't even have our public API isolated from
our implementation very well (yet). I would hate for this to be
delayed until that is in place.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Thu, Apr 3, 2014 at 3:24 PM, Sean Busbey <bu...@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 <vi...@apache.org> wrote:
>
>> +1
>>
>>
>> On Thu, Apr 3, 2014 at 2:15 PM, Christopher <ct...@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
>> >
>>
Re: [DISCUSS] Bugs-only strictness for bugfix releases
Posted by Bill Havanki <bh...@clouderagovt.com>.
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, <dl...@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 <bh...@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 <vi...@apache.org> wrote:
> >>
> >> > +1
> >> >
> >> >
> >> > On Thu, Apr 3, 2014 at 2:15 PM, Christopher <ct...@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
RE: [DISCUSS] Bugs-only strictness for bugfix releases
Posted by dl...@comcast.net.
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 <bh...@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 <bu...@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 <vi...@apache.org> wrote:
>>
>> > +1
>> >
>> >
>> > On Thu, Apr 3, 2014 at 2:15 PM, Christopher <ct...@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
Re: [DISCUSS] Bugs-only strictness for bugfix releases
Posted by Keith Turner <ke...@deenlo.com>.
On Thu, Apr 3, 2014 at 3:44 PM, Christopher <ct...@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 <bh...@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 <vi...@apache.org> wrote:
> >>
> >> > +1
> >> >
> >> >
> >> > On Thu, Apr 3, 2014 at 2:15 PM, Christopher <ct...@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
>
Re: [DISCUSS] Bugs-only strictness for bugfix releases
Posted by Mike Drob <ma...@cloudera.com>.
Forking is a good idea.
On Mon, Apr 7, 2014 at 10:48 AM, Christopher <ct...@apache.org> wrote:
> Mike,
>
> Bug would be non-conformance to intended/designed behavior, such that
> it causes failures in the application, regardless of who reported it.
> For instance, returning a null, when code that receives that returned
> value expects only non-null values, and the null value causes breakage
> in some way (intended action cannot be completed).
>
> Improvements would be things like "refactor internals to ease
> readability/writability", or "follow best practices", where the
> modifications don't result in an actual bug fix, but could help
> prevent future bugs. It could also be something where it's actually a
> bug (returning null values), but it cannot result in breakage, as that
> code path is never actually possible, and we just want to make the
> change to improve the API of that component, such that it will not
> result in a bug later if that code path does get exercised.
> Improvements could also be usability or minor modifications to an
> existing major feature (like adding a flag to sort the results, or
> adding an overloaded method which takes a String instead of byte[] for
> convenience).
>
> My intentions in updating these tickets had nothing to do with this
> issue, though (so perhaps we need to fork this thread?). Rather, they
> were routine quality checks in JIRA. My assumptions in these cases
> were that the reporter accepted the defaults instead of changing the
> issue type themselves. If that assumption is wrong, and they are
> actually resulting in bugs, I have no issue with documenting them as
> bugs. However, it would be nice if their descriptions included an
> explanation of the breakage, so that it's easy to understand as a bug.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Mon, Apr 7, 2014 at 8:45 AM, Mike Drob <ma...@cloudera.com> wrote:
> > Christopher,
> >
> > Can you provide a delineation between bug fix and improvement? I've
> noticed
> > that you recategorized several issues, including ACCUMULO-2638 and
> > ACCUMULO-2639 and was wondering what your criteria was for such.
> >
> > Is a bug-fix only something that has been reported by a user?
> >
> > Mike
> >
> >
> > On Fri, Apr 4, 2014 at 4:53 PM, Sean Busbey <bu...@cloudera.com> wrote:
> >
> >> None of our previous 1.x releases met semver's requirements for a minor
> >> version, so I don't think we need to worry about adopting that approach
> as
> >> a part of the 1.6.0 release cycle.
> >>
> >> There are a ton of reasons I want a 2.0.0. Given the significance of
> that
> >> change I think we should have a discussion about reqs.
> >>
> >> It's out of scope for this thread though.
> >>
> >>
> >> On Fri, Apr 4, 2014 at 6:46 PM, Christopher <ct...@apache.org>
> wrote:
> >>
> >> > It's probably true that 1.6.0 currently would not meet semver's
> >> > requirements for minor release compatibility, but something like this
> >> > I think should probably change at the beginning of a dev cycle, not at
> >> > the end. It seems to me that 1.7.0 would be the time to apply this,
> >> > considering it 1) has a different minimum JDK version, and 2) is
> >> > expected to contain a drastically improved client API module, where we
> >> > could actually apply maven plugins to ensure public API versioning
> >> > compliance naturally.
> >> >
> >> > --
> >> > Christopher L Tubbs II
> >> > http://gravatar.com/ctubbsii
> >> >
> >> >
> >> > On Fri, Apr 4, 2014 at 11:48 AM, <dl...@comcast.net> wrote:
> >> > > I don't know the specifics of the api changes in 1.6.0. But I would
> be
> >> > curious, if we applied the rules of something like semver, if the
> version
> >> > of code in the 1.6.0 branch is not consistent with the 1.6.0 version
> >> > number, but is maybe a 2.0.0.
> >> > >
> >> > > - Dave
> >> > >
> >> > > ----- Original Message -----
> >> > >
> >> > > From: dlmarion@comcast.net
> >> > > To: dev@accumulo.apache.org
> >> > > Sent: Thursday, April 3, 2014 6:59:44 PM
> >> > > Subject: RE: [DISCUSS] Bugs-only strictness for bugfix releases
> >> > >
> >> > >
> >> > > 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
> >> > >> <bu...@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 <vi...@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
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Sean
> >>
>
Re: [DISCUSS] Bugs-only strictness for bugfix releases
Posted by Christopher <ct...@apache.org>.
Mike,
Bug would be non-conformance to intended/designed behavior, such that
it causes failures in the application, regardless of who reported it.
For instance, returning a null, when code that receives that returned
value expects only non-null values, and the null value causes breakage
in some way (intended action cannot be completed).
Improvements would be things like "refactor internals to ease
readability/writability", or "follow best practices", where the
modifications don't result in an actual bug fix, but could help
prevent future bugs. It could also be something where it's actually a
bug (returning null values), but it cannot result in breakage, as that
code path is never actually possible, and we just want to make the
change to improve the API of that component, such that it will not
result in a bug later if that code path does get exercised.
Improvements could also be usability or minor modifications to an
existing major feature (like adding a flag to sort the results, or
adding an overloaded method which takes a String instead of byte[] for
convenience).
My intentions in updating these tickets had nothing to do with this
issue, though (so perhaps we need to fork this thread?). Rather, they
were routine quality checks in JIRA. My assumptions in these cases
were that the reporter accepted the defaults instead of changing the
issue type themselves. If that assumption is wrong, and they are
actually resulting in bugs, I have no issue with documenting them as
bugs. However, it would be nice if their descriptions included an
explanation of the breakage, so that it's easy to understand as a bug.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Mon, Apr 7, 2014 at 8:45 AM, Mike Drob <ma...@cloudera.com> wrote:
> Christopher,
>
> Can you provide a delineation between bug fix and improvement? I've noticed
> that you recategorized several issues, including ACCUMULO-2638 and
> ACCUMULO-2639 and was wondering what your criteria was for such.
>
> Is a bug-fix only something that has been reported by a user?
>
> Mike
>
>
> On Fri, Apr 4, 2014 at 4:53 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
>> None of our previous 1.x releases met semver's requirements for a minor
>> version, so I don't think we need to worry about adopting that approach as
>> a part of the 1.6.0 release cycle.
>>
>> There are a ton of reasons I want a 2.0.0. Given the significance of that
>> change I think we should have a discussion about reqs.
>>
>> It's out of scope for this thread though.
>>
>>
>> On Fri, Apr 4, 2014 at 6:46 PM, Christopher <ct...@apache.org> wrote:
>>
>> > It's probably true that 1.6.0 currently would not meet semver's
>> > requirements for minor release compatibility, but something like this
>> > I think should probably change at the beginning of a dev cycle, not at
>> > the end. It seems to me that 1.7.0 would be the time to apply this,
>> > considering it 1) has a different minimum JDK version, and 2) is
>> > expected to contain a drastically improved client API module, where we
>> > could actually apply maven plugins to ensure public API versioning
>> > compliance naturally.
>> >
>> > --
>> > Christopher L Tubbs II
>> > http://gravatar.com/ctubbsii
>> >
>> >
>> > On Fri, Apr 4, 2014 at 11:48 AM, <dl...@comcast.net> wrote:
>> > > I don't know the specifics of the api changes in 1.6.0. But I would be
>> > curious, if we applied the rules of something like semver, if the version
>> > of code in the 1.6.0 branch is not consistent with the 1.6.0 version
>> > number, but is maybe a 2.0.0.
>> > >
>> > > - Dave
>> > >
>> > > ----- Original Message -----
>> > >
>> > > From: dlmarion@comcast.net
>> > > To: dev@accumulo.apache.org
>> > > Sent: Thursday, April 3, 2014 6:59:44 PM
>> > > Subject: RE: [DISCUSS] Bugs-only strictness for bugfix releases
>> > >
>> > >
>> > > 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
>> > >> <bu...@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 <vi...@apache.org> wrote:
>> > >>>
>> > >>> > +1
>> > >>> >
>> > >>> >
>> > >>> > On Thu, Apr 3, 2014 at 2:15 PM, Christopher <ct...@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
>> > >
>> >
>>
>>
>>
>> --
>> Sean
>>
Re: [DISCUSS] Bugs-only strictness for bugfix releases
Posted by William Slacum <wi...@accumulo.net>.
A bug would be something that's an actual issue outside of the expected
behavior of the program-- for instance, if we're getting a
NullPointerException while running a scan of a table that worked in a
previous state of the source code.
An improvement would be something that makes us better off, but doesn't
address any behavioral issues. I would say something like resolving
compiler warnings or your ticket regarding the use of try-with-resources.
On Mon, Apr 7, 2014 at 8:45 AM, Mike Drob <ma...@cloudera.com> wrote:
> Christopher,
>
> Can you provide a delineation between bug fix and improvement? I've noticed
> that you recategorized several issues, including ACCUMULO-2638 and
> ACCUMULO-2639 and was wondering what your criteria was for such.
>
> Is a bug-fix only something that has been reported by a user?
>
> Mike
>
>
> On Fri, Apr 4, 2014 at 4:53 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
> > None of our previous 1.x releases met semver's requirements for a minor
> > version, so I don't think we need to worry about adopting that approach
> as
> > a part of the 1.6.0 release cycle.
> >
> > There are a ton of reasons I want a 2.0.0. Given the significance of
> that
> > change I think we should have a discussion about reqs.
> >
> > It's out of scope for this thread though.
> >
> >
> > On Fri, Apr 4, 2014 at 6:46 PM, Christopher <ct...@apache.org> wrote:
> >
> > > It's probably true that 1.6.0 currently would not meet semver's
> > > requirements for minor release compatibility, but something like this
> > > I think should probably change at the beginning of a dev cycle, not at
> > > the end. It seems to me that 1.7.0 would be the time to apply this,
> > > considering it 1) has a different minimum JDK version, and 2) is
> > > expected to contain a drastically improved client API module, where we
> > > could actually apply maven plugins to ensure public API versioning
> > > compliance naturally.
> > >
> > > --
> > > Christopher L Tubbs II
> > > http://gravatar.com/ctubbsii
> > >
> > >
> > > On Fri, Apr 4, 2014 at 11:48 AM, <dl...@comcast.net> wrote:
> > > > I don't know the specifics of the api changes in 1.6.0. But I would
> be
> > > curious, if we applied the rules of something like semver, if the
> version
> > > of code in the 1.6.0 branch is not consistent with the 1.6.0 version
> > > number, but is maybe a 2.0.0.
> > > >
> > > > - Dave
> > > >
> > > > ----- Original Message -----
> > > >
> > > > From: dlmarion@comcast.net
> > > > To: dev@accumulo.apache.org
> > > > Sent: Thursday, April 3, 2014 6:59:44 PM
> > > > Subject: RE: [DISCUSS] Bugs-only strictness for bugfix releases
> > > >
> > > >
> > > > 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
> > > >> <bu...@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 <vi...@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
> > > >
> > >
> >
> >
> >
> > --
> > Sean
> >
>
Re: [DISCUSS] Bugs-only strictness for bugfix releases
Posted by Mike Drob <ma...@cloudera.com>.
Christopher,
Can you provide a delineation between bug fix and improvement? I've noticed
that you recategorized several issues, including ACCUMULO-2638 and
ACCUMULO-2639 and was wondering what your criteria was for such.
Is a bug-fix only something that has been reported by a user?
Mike
On Fri, Apr 4, 2014 at 4:53 PM, Sean Busbey <bu...@cloudera.com> wrote:
> None of our previous 1.x releases met semver's requirements for a minor
> version, so I don't think we need to worry about adopting that approach as
> a part of the 1.6.0 release cycle.
>
> There are a ton of reasons I want a 2.0.0. Given the significance of that
> change I think we should have a discussion about reqs.
>
> It's out of scope for this thread though.
>
>
> On Fri, Apr 4, 2014 at 6:46 PM, Christopher <ct...@apache.org> wrote:
>
> > It's probably true that 1.6.0 currently would not meet semver's
> > requirements for minor release compatibility, but something like this
> > I think should probably change at the beginning of a dev cycle, not at
> > the end. It seems to me that 1.7.0 would be the time to apply this,
> > considering it 1) has a different minimum JDK version, and 2) is
> > expected to contain a drastically improved client API module, where we
> > could actually apply maven plugins to ensure public API versioning
> > compliance naturally.
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> >
> > On Fri, Apr 4, 2014 at 11:48 AM, <dl...@comcast.net> wrote:
> > > I don't know the specifics of the api changes in 1.6.0. But I would be
> > curious, if we applied the rules of something like semver, if the version
> > of code in the 1.6.0 branch is not consistent with the 1.6.0 version
> > number, but is maybe a 2.0.0.
> > >
> > > - Dave
> > >
> > > ----- Original Message -----
> > >
> > > From: dlmarion@comcast.net
> > > To: dev@accumulo.apache.org
> > > Sent: Thursday, April 3, 2014 6:59:44 PM
> > > Subject: RE: [DISCUSS] Bugs-only strictness for bugfix releases
> > >
> > >
> > > 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
> > >> <bu...@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 <vi...@apache.org> wrote:
> > >>>
> > >>> > +1
> > >>> >
> > >>> >
> > >>> > On Thu, Apr 3, 2014 at 2:15 PM, Christopher <ct...@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
> > >
> >
>
>
>
> --
> Sean
>
Re: [DISCUSS] Bugs-only strictness for bugfix releases
Posted by Josh Elser <jo...@gmail.com>.
On 4/7/14, 10:53 AM, Keith Turner wrote:
> On Mon, Apr 7, 2014 at 10:43 AM, Josh Elser<jo...@gmail.com> wrote:
>
>> >I agree that our release "model" doesn't fully allow for a proper breadth
>> >of "changes" to the codebase.
>> >
>> >My view of the current model is as Christopher described (long-term
>> >support and bugfix); however, how it was also described by a few others,
>> >the community wants "more" than this model provides
>> >
>> >And, sorry for the tangent, but I be strongly in favor of 1.7 == 2.0 for
>> >numerous reasons, one of the biggest being this discussion.
>> >
>> >As far as this discussion goes, I don't think we have the ability to
>> >maintain explicit bug-fix only (as described by "only fixes that cause
>> >errors") since things often get refactored internally for better test
>> >coverage, now invalidated assumptions, etc. I'd be in favor of playing
>> >fast-and-loose for the 1.x releases how we have (keeping each other honest)
>> >and follow an explicit model that doesn't have ambiguity in regards to
>> >interpretation for 2.0 (what is now 1.7).
>
> Another argument for trying to better define the 1.[456].[0-9] release
> going forward is saving our own time. We will be living with these lines
> for a while. Continually debating each change that goes into them is a
> complete waste of our time.
>
I agree completely. This is the first time we've had this discussion --
certainly won't be the last.
Re: [DISCUSS] Bugs-only strictness for bugfix releases
Posted by Keith Turner <ke...@deenlo.com>.
On Mon, Apr 7, 2014 at 10:43 AM, Josh Elser <jo...@gmail.com> wrote:
> I agree that our release "model" doesn't fully allow for a proper breadth
> of "changes" to the codebase.
>
> My view of the current model is as Christopher described (long-term
> support and bugfix); however, how it was also described by a few others,
> the community wants "more" than this model provides
>
> And, sorry for the tangent, but I be strongly in favor of 1.7 == 2.0 for
> numerous reasons, one of the biggest being this discussion.
>
> As far as this discussion goes, I don't think we have the ability to
> maintain explicit bug-fix only (as described by "only fixes that cause
> errors") since things often get refactored internally for better test
> coverage, now invalidated assumptions, etc. I'd be in favor of playing
> fast-and-loose for the 1.x releases how we have (keeping each other honest)
> and follow an explicit model that doesn't have ambiguity in regards to
> interpretation for 2.0 (what is now 1.7).
Another argument for trying to better define the 1.[456].[0-9] release
going forward is saving our own time. We will be living with these lines
for a while. Continually debating each change that goes into them is a
complete waste of our time.
>
>
> On 4/4/14, 7:53 PM, Sean Busbey wrote:
>
>> None of our previous 1.x releases met semver's requirements for a minor
>> version, so I don't think we need to worry about adopting that approach as
>> a part of the 1.6.0 release cycle.
>>
>> There are a ton of reasons I want a 2.0.0. Given the significance of that
>> change I think we should have a discussion about reqs.
>>
>> It's out of scope for this thread though.
>>
>>
>> On Fri, Apr 4, 2014 at 6:46 PM, Christopher <ct...@apache.org> wrote:
>>
>> It's probably true that 1.6.0 currently would not meet semver's
>>> requirements for minor release compatibility, but something like this
>>> I think should probably change at the beginning of a dev cycle, not at
>>> the end. It seems to me that 1.7.0 would be the time to apply this,
>>> considering it 1) has a different minimum JDK version, and 2) is
>>> expected to contain a drastically improved client API module, where we
>>> could actually apply maven plugins to ensure public API versioning
>>> compliance naturally.
>>>
>>> --
>>> Christopher L Tubbs II
>>> http://gravatar.com/ctubbsii
>>>
>>>
>>> On Fri, Apr 4, 2014 at 11:48 AM, <dl...@comcast.net> wrote:
>>>
>>>> I don't know the specifics of the api changes in 1.6.0. But I would be
>>>>
>>> curious, if we applied the rules of something like semver, if the version
>>> of code in the 1.6.0 branch is not consistent with the 1.6.0 version
>>> number, but is maybe a 2.0.0.
>>>
>>>>
>>>> - Dave
>>>>
>>>> ----- Original Message -----
>>>>
>>>> From: dlmarion@comcast.net
>>>> To: dev@accumulo.apache.org
>>>> Sent: Thursday, April 3, 2014 6:59:44 PM
>>>> Subject: RE: [DISCUSS] Bugs-only strictness for bugfix releases
>>>>
>>>>
>>>> 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
>>>>> <bu...@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 <vi...@apache.org> wrote:
>>>>>>
>>>>>> +1
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Apr 3, 2014 at 2:15 PM, Christopher <ct...@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
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
Re: [DISCUSS] Bugs-only strictness for bugfix releases
Posted by Josh Elser <jo...@gmail.com>.
I agree that our release "model" doesn't fully allow for a proper
breadth of "changes" to the codebase.
My view of the current model is as Christopher described (long-term
support and bugfix); however, how it was also described by a few others,
the community wants "more" than this model provides
And, sorry for the tangent, but I be strongly in favor of 1.7 == 2.0 for
numerous reasons, one of the biggest being this discussion.
As far as this discussion goes, I don't think we have the ability to
maintain explicit bug-fix only (as described by "only fixes that cause
errors") since things often get refactored internally for better test
coverage, now invalidated assumptions, etc. I'd be in favor of playing
fast-and-loose for the 1.x releases how we have (keeping each other
honest) and follow an explicit model that doesn't have ambiguity in
regards to interpretation for 2.0 (what is now 1.7).
On 4/4/14, 7:53 PM, Sean Busbey wrote:
> None of our previous 1.x releases met semver's requirements for a minor
> version, so I don't think we need to worry about adopting that approach as
> a part of the 1.6.0 release cycle.
>
> There are a ton of reasons I want a 2.0.0. Given the significance of that
> change I think we should have a discussion about reqs.
>
> It's out of scope for this thread though.
>
>
> On Fri, Apr 4, 2014 at 6:46 PM, Christopher <ct...@apache.org> wrote:
>
>> It's probably true that 1.6.0 currently would not meet semver's
>> requirements for minor release compatibility, but something like this
>> I think should probably change at the beginning of a dev cycle, not at
>> the end. It seems to me that 1.7.0 would be the time to apply this,
>> considering it 1) has a different minimum JDK version, and 2) is
>> expected to contain a drastically improved client API module, where we
>> could actually apply maven plugins to ensure public API versioning
>> compliance naturally.
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>>
>> On Fri, Apr 4, 2014 at 11:48 AM, <dl...@comcast.net> wrote:
>>> I don't know the specifics of the api changes in 1.6.0. But I would be
>> curious, if we applied the rules of something like semver, if the version
>> of code in the 1.6.0 branch is not consistent with the 1.6.0 version
>> number, but is maybe a 2.0.0.
>>>
>>> - Dave
>>>
>>> ----- Original Message -----
>>>
>>> From: dlmarion@comcast.net
>>> To: dev@accumulo.apache.org
>>> Sent: Thursday, April 3, 2014 6:59:44 PM
>>> Subject: RE: [DISCUSS] Bugs-only strictness for bugfix releases
>>>
>>>
>>> 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 <bh...@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
>>>> <bu...@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 <vi...@apache.org> wrote:
>>>>>
>>>>>> +1
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 3, 2014 at 2:15 PM, Christopher <ct...@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
>>>
>>
>
>
>
Re: [DISCUSS] Bugs-only strictness for bugfix releases
Posted by Sean Busbey <bu...@cloudera.com>.
None of our previous 1.x releases met semver's requirements for a minor
version, so I don't think we need to worry about adopting that approach as
a part of the 1.6.0 release cycle.
There are a ton of reasons I want a 2.0.0. Given the significance of that
change I think we should have a discussion about reqs.
It's out of scope for this thread though.
On Fri, Apr 4, 2014 at 6:46 PM, Christopher <ct...@apache.org> wrote:
> It's probably true that 1.6.0 currently would not meet semver's
> requirements for minor release compatibility, but something like this
> I think should probably change at the beginning of a dev cycle, not at
> the end. It seems to me that 1.7.0 would be the time to apply this,
> considering it 1) has a different minimum JDK version, and 2) is
> expected to contain a drastically improved client API module, where we
> could actually apply maven plugins to ensure public API versioning
> compliance naturally.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Fri, Apr 4, 2014 at 11:48 AM, <dl...@comcast.net> wrote:
> > I don't know the specifics of the api changes in 1.6.0. But I would be
> curious, if we applied the rules of something like semver, if the version
> of code in the 1.6.0 branch is not consistent with the 1.6.0 version
> number, but is maybe a 2.0.0.
> >
> > - Dave
> >
> > ----- Original Message -----
> >
> > From: dlmarion@comcast.net
> > To: dev@accumulo.apache.org
> > Sent: Thursday, April 3, 2014 6:59:44 PM
> > Subject: RE: [DISCUSS] Bugs-only strictness for bugfix releases
> >
> >
> > 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 <bh...@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
> >> <bu...@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 <vi...@apache.org> wrote:
> >>>
> >>> > +1
> >>> >
> >>> >
> >>> > On Thu, Apr 3, 2014 at 2:15 PM, Christopher <ct...@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
> >
>
--
Sean
Re: [DISCUSS] Bugs-only strictness for bugfix releases
Posted by Christopher <ct...@apache.org>.
It's probably true that 1.6.0 currently would not meet semver's
requirements for minor release compatibility, but something like this
I think should probably change at the beginning of a dev cycle, not at
the end. It seems to me that 1.7.0 would be the time to apply this,
considering it 1) has a different minimum JDK version, and 2) is
expected to contain a drastically improved client API module, where we
could actually apply maven plugins to ensure public API versioning
compliance naturally.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Fri, Apr 4, 2014 at 11:48 AM, <dl...@comcast.net> wrote:
> I don't know the specifics of the api changes in 1.6.0. But I would be curious, if we applied the rules of something like semver, if the version of code in the 1.6.0 branch is not consistent with the 1.6.0 version number, but is maybe a 2.0.0.
>
> - Dave
>
> ----- Original Message -----
>
> From: dlmarion@comcast.net
> To: dev@accumulo.apache.org
> Sent: Thursday, April 3, 2014 6:59:44 PM
> Subject: RE: [DISCUSS] Bugs-only strictness for bugfix releases
>
>
> 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 <bh...@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
>> <bu...@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 <vi...@apache.org> wrote:
>>>
>>> > +1
>>> >
>>> >
>>> > On Thu, Apr 3, 2014 at 2:15 PM, Christopher <ct...@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
>
Re: [DISCUSS] Bugs-only strictness for bugfix releases
Posted by dl...@comcast.net.
I don't know the specifics of the api changes in 1.6.0. But I would be curious, if we applied the rules of something like semver, if the version of code in the 1.6.0 branch is not consistent with the 1.6.0 version number, but is maybe a 2.0.0.
- Dave
----- Original Message -----
From: dlmarion@comcast.net
To: dev@accumulo.apache.org
Sent: Thursday, April 3, 2014 6:59:44 PM
Subject: RE: [DISCUSS] Bugs-only strictness for bugfix releases
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 <bh...@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
> <bu...@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 <vi...@apache.org> wrote:
>>
>> > +1
>> >
>> >
>> > On Thu, Apr 3, 2014 at 2:15 PM, Christopher <ct...@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
Re: [DISCUSS] Bugs-only strictness for bugfix releases
Posted by Christopher <ct...@apache.org>.
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 <bh...@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 <bu...@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 <vi...@apache.org> wrote:
>>
>> > +1
>> >
>> >
>> > On Thu, Apr 3, 2014 at 2:15 PM, Christopher <ct...@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
Re: [DISCUSS] Bugs-only strictness for bugfix releases
Posted by Bill Havanki <bh...@clouderagovt.com>.
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 <bu...@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 <vi...@apache.org> wrote:
>
> > +1
> >
> >
> > On Thu, Apr 3, 2014 at 2:15 PM, Christopher <ct...@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
Re: [DISCUSS] Bugs-only strictness for bugfix releases
Posted by Sean Busbey <bu...@cloudera.com>.
-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 <vi...@apache.org> wrote:
> +1
>
>
> On Thu, Apr 3, 2014 at 2:15 PM, Christopher <ct...@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
> >
>
Re: [DISCUSS] Bugs-only strictness for bugfix releases
Posted by John Vines <vi...@apache.org>.
+1
On Thu, Apr 3, 2014 at 2:15 PM, Christopher <ct...@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
>