Won't we then find another reason next release? I agree with Stack, that we should only provide a guaranteed and tested upgrade path from one release to the next.
In this specific case it's fine to to remove that code later since (as you say) it is not causing problems and is not holding up other development. Let's target this for 0.96 then? I.e. the script goes into 0.94 and in 0.96 we remove HFile v1. Are you against incorporation of HBASE-2600? Someone needs to verify that this is not causing upgrade problems from 0.90. -- Lars ----- Original Message ----- From: Todd Lipcon <[email protected]> To: [email protected] Cc: lars hofhansl <[email protected]> Sent: Friday, January 27, 2012 7:20 AM Subject: Re: hbase 0.94.0 On Thu, Jan 26, 2012 at 9:13 PM, Stack <[email protected]> wrote: > > -1 on our working on stuff to make it easier to skip intermediary > versions. Migrations are hard enough going between particular > versions already. Support for skipping versions seems like a waste of > our time (For the historians in the audience, see our migration doc. > 'General Migration Notes' [1] where we are explicit that you must step > up through the versions -- you can't skip versions upgrading). Yes and no... from our CDH perspective, if 0.94.x is out by the time we need to get CDH4 "GA", then we'll skip from 0.90.x in CDH3 to 0.94.x in CDH4, and hence we need an upgrade path. So if upstream doesn't support it, we'll have to hack it in as a CDH special. That's fine -- but if there's no change that forces us to break compatibility, why break it? -Todd -- Todd Lipcon Software Engineer, Cloudera
