accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dlmar...@comcast.net
Subject Re: [DISCUSS] Bugs-only strictness for bugfix releases
Date Fri, 04 Apr 2014 15:48:45 GMT
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