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 <bus...@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 <la...@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 <apurt...@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
