accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [DISCUSS] Bugs-only strictness for bugfix releases
Date Mon, 07 Apr 2014 14:53:01 GMT
On Mon, Apr 7, 2014 at 10:43 AM, Josh Elser <josh.elser@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 <ctubbsii@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,  <dlmarion@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
>>>>> <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message