accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Bugs-only strictness for bugfix releases
Date Thu, 03 Apr 2014 19:44:35 GMT
I don't think that's it's quite true to say '1.major.minor' is our de
facto scheme. Once again, I think many of us have always viewed it as
'1.long-term-support.bugfix'.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Thu, Apr 3, 2014 at 3:39 PM, Bill Havanki <bhavanki@clouderagovt.com> wrote:
> I agree with Christopher in principle, but I share Sean's concern about the
> versioning situation. Right now, the *de facto* versioning scheme is
> 1.major.minor. We should just adopt semantic versioning (or similar) and
> then enforce bugs-only for bugfix releases. This gives us the room we need.
>
> For reference: semver.org
>
>
> On Thu, Apr 3, 2014 at 3:24 PM, Sean Busbey <busbey+lists@cloudera.com>wrote:
>
>> -1
>>
>> Until we have a full discussion on compatibility and what we're going to
>> mean for version numbers, this is counter productive to our
>> volunteer-driven CtR process. That some of us choose to focus our resources
>> on more recent major versions is irrelevant.
>>
>> Right now, we conflate minor and bugfix versions. This change would mean
>> instead conflating our major and minor versions. That's going to make it
>> harder for people to upgrade for compatible improvements because the
>> inclusion of the major changes will be disruptive.
>>
>> We need to have the compatibility and versioning discussion. This band aid
>> won't help.
>>
>>
>> On Thu, Apr 3, 2014 at 2:16 PM, John Vines <vines@apache.org> wrote:
>>
>> > +1
>> >
>> >
>> > On Thu, Apr 3, 2014 at 2:15 PM, Christopher <ctubbsii@apache.org> wrote:
>> >
>> > > JIRA JQL:
>> > > 'project = ACCUMULO  AND resolution = Unresolved AND type not in
>> > > (Sub-task, Bug) AND fixVersion in (1.4.6,1.5.2,1.6.1)'
>> > >
>> > > There are 32 outstanding issues not marked as "Bugs" planned for
>> > > bugfix releases. This seems inappropriate to me. I would prefer to be
>> > > very strict about the right-most segment of a version number, by
>> > > defining it as "for bugfix releases", and by following the rule: if
>> > > the issue doesn't fix a bug, then it doesn't go in a bugfix release.
>> > >
>> > > This strictness could help us focus on fixing and supporting actual
>> > > bugs in previous releases, without being bogged down by non-bugs, it
>> > > could help focus improvements in the latest version and encourage more
>> > > rapid releases, and give users more reasons to upgrade. It would also
>> > > help stabilize previous releases, by avoiding the introduction of new
>> > > bugs, which bodes well for long-term support.
>> > >
>> > > I know we've previously talked about semver and other strict
>> > > versioning schemes, but regardless of whether we do any of those other
>> > > things, I think this strictness is the very least we could do, and we
>> > > could start encouraging this strictness today, with minimal impact.
>> > > All it would take is to define the last segment of the versioned
>> > > releases as "for bugfix releases", regardless of defining the rest of
>> > > the version number (which can be discussed separately, and this is a
>> > > subset of most any versioning scheme we've discussed already).
>> > >
>> > > The implication is that some things we've done in the past to
>> > > "backport" improvements and features, which didn't address a bug,
>> > > would no longer be permitted. Or, at the very least, would have been
>> > > highly discouraged, or would have warranted a vote (see next
>> > > paragraph).
>> > >
>> > > As with anything, there may be important exceptions, so perhaps with
>> > > this strictness about "bugfix only for bugfix releases", we could
>> > > encourage (by convention, if not by policy) calling a vote for
>> > > non-bugfix changes, and rely on the veto for enforcement if a
>> > > non-bugfix was applied to a bugfix version. If we agree to this
>> > > strictness as a community, knowing a particular change is likely to
>> > > result in a veto can be a big help in discouraging violations.
>> > >
>> > > As a final note, I should mention that there are at least a few of us
>> > > who have been thinking about this last segment of the version as
>> > > "bugfix only" anyways, if only informally. The lack of
>> > > formalization/strictness about this, though, has permitted some things
>> > > in the past that are probably not the best ideas in terms of stability
>> > > and long-term support of previous release lines. Hopefully, by
>> > > adopting this strictness as a community, instead of just informally in
>> > > a few of our heads, we can all get on the same page, and it will make
>> > > the project better overall.
>> > >
>> > > --
>> > > Christopher L Tubbs II
>> > > http://gravatar.com/ctubbsii
>> > >
>> >
>>
>
>
>
> --
> // Bill Havanki
> // Solutions Architect, Cloudera Govt Solutions
> // 443.686.9283

Mime
View raw message