Is there anything in 1.4* not in 1.2 that would warrant that? Otherwise I agree, not requiring an intermediate upgrade step would be best. Requiring a double upgrade would be super operator unfriendly.
* - Should everything go reasonably well we will have a 1.4.0 release before December. I'm going to do the first RC next week. > On Oct 28, 2017, at 5:09 PM, Mike Drob <mad...@cloudera.com> wrote: > > Ok, looks like there is some enough feelings that we don't need to worry > about downgrades. > > What about the other part of Sean's question? Do we need to support rolling > upgrades to 2.0 from any 1.x, or is it fair game to require a specific > minimum version? > > If we felt that it simplified things, I'd even be happy with a minimum > 1.4->2.0 upgrade path, but 1.4 doesn't exist yet and I don't feel like > that's something we can dictate to users. Maybe it's ok to set the minimum > line at 1.2? If we end up moving the stable pointer, that makes for a > stronger argument for a newer minimum version. > > Mike > >> On Sat, Oct 28, 2017 at 4:46 PM, Josh Elser <josh.el...@gmail.com> wrote: >> >> +1 -- well put, Andrew. >> >> >>> On 10/28/17 1:17 PM, Andrew Purtell wrote: >>> >>> I would not like to see downgrades as a goal. This would be new. We've >>> not done it before. Laudible goal, but we are clearly stretched already. >>> >>> >>>> On Oct 28, 2017, at 10:08 AM, Mike Drob <md...@apache.org> wrote: >>>> >>>> If downgrades are a later goal, does that mean somebody could go from >>>> some >>>> 1.x to 2.0 to 2.y then back to 1.x? >>>> >>>>> On Fri, Oct 27, 2017 at 10:42 PM, Sean Busbey <bus...@apache.org> wrote: >>>>> >>>>> I'd like to make downgrades a non-goal. I'd love us to support >>>>> downgrades eventually, but that's a feature in its own right and I >>>>> don't think we have time to get it done and still have a 2.0.0 GA in a >>>>> reasonable time frame. >>>>> >>>>> On Fri, Oct 27, 2017 at 10:40 PM, Sean Busbey <bus...@apache.org> >>>>>> wrote: >>>>>> A recent JIRA about our hfile format[1] has got me thinking about >>>>>> expectations for upgrading. The specifics of that JIRA aren't terribly >>>>>> important; it's the general issue I want to talk about. A >>>>>> simplification of the mismatch in expectations between two groups is >>>>>> that some folks place the bar for "we support rolling upgrade" at >>>>>> rolling upgrade from 1.y.z* versions generally and others are >>>>>> comfortable requiring an initial upgrade to some later 1.y.z version >>>>>> first. >>>>>> >>>>>> Have we documented what our goals are for upgrades this major release? >>>>>> Do we know what we have to do to get there? I've seen a few one-off >>>>>> JIRAs to fix particular problems, but not really a plan. >>>>>> >>>>>> We should discuss here a bit. >>>>>> >>>>>> When things have some consensus is anyone willing to take point on >>>>>> writing up the results in a scope document of sorts? I have a few good >>>>>> examples to point you to, though they're all for features. >>>>>> >>>>>> >>>>>> [1]: https://issues.apache.org/jira/browse/HBASE-19052 >>>>>> >>>>> >>>>>
