Ok, then it's covered. On Sun, Oct 29, 2017 at 10:35 PM, Stack <[email protected]> wrote:
> I was going to do 1.2... > S > > On Sun, Oct 29, 2017 at 9:52 AM, Andrew Purtell <[email protected]> > wrote: > > > I'll check how upgrade fares from 1.4 to 2.0 while exercising the 1.4.0 > > candidates for release. Can someone do that for 1.2? > > > > > > > On Oct 29, 2017, at 9:11 AM, Mike Drob <[email protected]> wrote: > > > > > > I think the crux of the issue is that nobody's done the work to find > out. > > > > > > On Sat, Oct 28, 2017 at 8:24 PM, Andrew Purtell < > > [email protected]> > > > wrote: > > > > > >> 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 <[email protected]> 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 <[email protected]> > > >> 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 <[email protected]> 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 <[email protected] > > > > >> 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 <[email protected] > > > > >>>>>>>> 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 > > >>>>>>>> > > >>>>>>> > > >>>>>>> > > > >
