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, <[email protected]> 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: [email protected]
To: [email protected]
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: [email protected] [mailto:[email protected]] 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 <[email protected]>
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
<[email protected]>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 <[email protected]> wrote:
+1
On Thu, Apr 3, 2014 at 2:15 PM, Christopher <[email protected]>
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
