hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Latham <lat...@davelink.net>
Subject Re: 0.98 patch acceptance criteria discussion
Date Fri, 17 Jul 2015 15:26:57 GMT
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