hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <andrew.purt...@gmail.com>
Subject Re: 0.98 patch acceptance criteria discussion
Date Fri, 17 Jul 2015 15:48:06 GMT
> So "newer" has some extra meaning.  In practice it seems to mean the a
> release is "newer" if it's from a minor branch that was branched at a
> later date.  That's a hard thing for a user to know.  How do we meet
> the user's expectation with that definition? We need to make it
> visible.  Give users a way to understand what releases are "newer" 
> than others. 

For that we could possibly adopt something suitable or build a plugin for doc and site generation
that extracts release tags from git during build and renders them into a timeline. 


> On Jul 17, 2015, at 8:26 AM, Dave Latham <latham@davelink.net> wrote:
> 
> My thoughts on the patches and versions issue.  Apologies as this
> overlaps some of what others said, since I got the notes in order.
> 
> All of this stems from trying to make life easier for our users and
> meet their expectations.  Here's what I think are the relevant user
> expectations:
> - Upgrading to a new patch release should not break my app.
>   - Therefore patch releases only include bug fixes to maintain
> stability (semver).
> - Upgrading to a new minor release should be able to happen without
> downtime to my system.
>   - Therefore minor releases should be rolling upgradeable and
> preserve most forms of compatibility (semver - see the table in the
> HBase book for details).
> - Upgrading to a "newer" release should not lose any features or bug
> fixes that I already had.
>   - Therefore ???
> 
> This last point seems to be the question that started this discussion.
> Is that expectation reasonable and if so, what policies do we need to
> adopt regarding commits, branches, and releases to meet it?
> 
> I think it's reasonable depending on what "newer" means.  If we say
> that a version with a greater major number is always newer than a
> version with a lesser major number (and likewise for minors) then we
> essentially have to put all releases in strict sequence.  We've never
> had that expectation.  For example, if someone upgraded from 0.94.27
> to 0.96.0 or from 0.98.14 to 1.0.0 they would lose some features and
> many bug fixes - hopefully not a surprise.  Similarly for minor
> upgrades, it should not be a surprise if someone upgrades (someday)
> from 1.0.22 to 1.1.0 that they may lose many bug fixes.
> 
> So "newer" has some extra meaning.  In practice it seems to mean the a
> release is "newer" if it's from a minor branch that was branched at a
> later date.  That's a hard thing for a user to know.  How do we meet
> the user's expectation with that definition? We need to make it
> visible.  Give users a way to understand what releases are "newer"
> than others.  Tell users they should only do upgrades to "newer"
> releases (should those be the only upgrades supported?).  Sean
> suggested each release indicate the minimum minor release of the next
> major which seems helpful.  Showing a release date history or minor
> branch history somewhere may help (does it already exist?).  We could
> keep some sort of graph showing the relationships.
> 
> What does this mean for commits and branches?  Here's the approach
> that I think is about what I've observed so far:
> - Commit incompatible changes to master only
> - Commit compatible features to master first, then major, non-EOL
> branches in reverse order (master, branch-2, branch-1, 0.98, 0.94) as
> far back as accepted by RMs.  In other words, *don't commit a feature
> to a major branch unless master and all greater major, non-EOL
> branches already have it.*
> - Commit bug fixes to master first, then major, non-EOL branches in
> reverse order as accepted by RMs, then minor, non-EOL branches in
> reverse "newer" order as accepted by RMs.  In other words *don't
> commit a bug fix to a minor branch unless master, the related major
> branch, and all greater, "newer", minor, non-EOL branches already have
> it.*  I.e. if 2.2 is "newer" than 1.3, be sure that 2.2 has the fix
> before 1.3 gets it.
> 
> There will likely be some exceptions made by RM judgement and RMs will
> have to deal with the notions of whether "newer" lines block older
> ones from getting commits or older ones force "newer" ones.  But we
> should keep in mind that whenever we make those exceptions we may
> break user expectations.
> 
> Another thing that this means is that if minor releases from a new
> major version come at a significantly slower pace than minor releases
> from a previous major version that users could be stuck on a previous
> major release, wanting to upgrade to a newer major release but waiting
> for a "newer" minor release on that major line to happen.  We should
> try to avoid that situation by not waiting too long for "newer" minor
> releases on greater major releases after updating older major
> releases.
> 
> Dave
> 
> On Fri, Jul 17, 2015 at 7:31 AM, Sean Busbey <busbey@cloudera.com> wrote:
>>> I think the extra statement we have to make is that only the latest minor
>> version of the next major branch
>>> is guaranteed have all the improvements of the previous major branch.Or
>> phrased in other words:
>>> Improvements that are not bug fixes will only go into the x.y.0 minor
>> version, but not (by default anyway,
>>> the RM should use good judgment) into any existing minor version (and
>> thus not in a patch version > 0)
>> 
>> I think that's a fine statement.
>> 
>> I don't know if it's worth doing, but we could say in each minor release's
>> notes what the minimum minor release in the next major version is needed to
>> get a superset of functionality. This would only really impact Andrew right
>> now since all the 1.y.0 versions would be "2.0".
>> 
>> 
>>> On Fri, Jul 17, 2015 at 8:47 AM, lars hofhansl <larsh@apache.org> wrote:
>>> 
>>> Thanks Andy.
>>> I think the gist of the discussion boils down to this:We generally have
>>> two goals: (1) follow semver from 1.0.0 onward and (2) avoid losing
>>> features/improvements when upgrading from an older version to a newer one.
>>> Turns out these two are conflicting unless we follow certain additional
>>> policies.
>>> The issue at hand was a performance improvement that we added to 0.98,
>>> 1.3.0, and 2.0.0, but not 1.0.x, 1.1.x, and 1.2.x (x >= 1 in all cases)So
>>> when somebody would upgrade from 0.98 to (say) 1.1.7 (if/when that's out)
>>> that improvement would "silently" be lost.
>>> I think the extra statement we have to make is that only the latest minor
>>> version of the next major branch is guaranteed have all the improvements of
>>> the previous major branch.Or phrased in other words: Improvements that are
>>> not bug fixes will only go into the x.y.0 minor version, but not (by
>>> default anyway, the RM should use good judgment) into any existing minor
>>> version (and thus not in a patch version > 0)
>>> 
>>> If that's OK with everybody we can just state that and move on (and I'll
>>> shut up :) ).
>>> -- Lars
>>> 
>>>      From: Andrew Purtell <apurtell@apache.org>
>>> To: "dev@hbase.apache.org" <dev@hbase.apache.org>
>>> Sent: Thursday, July 16, 2015 8:58 AM
>>> Subject: 0.98 patch acceptance criteria discussion
>>> 
>>> Hi devs,
>>> 
>>> I'd like to call your attention to an interesting and important discussion
>>> taking place on the tail of HBASE-12596. It starts from here:
>>> 
>>> https://issues.apache.org/jira/browse/HBASE-12596?focusedCommentId=14628295&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14628295
>>> 
>>> --
>>> Best regards,
>>> 
>>>  - Andy
>>> 
>>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>>> (via Tom White)
>> 
>> 
>> 
>> --
>> Sean

Mime
View raw message