accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <>
Subject Re: [DISCUSS] Bugs-only strictness for bugfix releases
Date Thu, 03 Apr 2014 19:16:09 GMT

On Thu, Apr 3, 2014 at 2:15 PM, Christopher <> wrote:

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

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