accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject [DISCUSS] Bugs-only strictness for bugfix releases
Date Thu, 03 Apr 2014 18:15:31 GMT
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

Mime
View raw message