No more discussions or interest? Already discussed to death elsewhere?

I want to go ahead with the proposal only if it makes sense for the
community. I think it will be very good if we can have 4.4.0 release(s) to
support both HBase-0.98 and HBase-1.0 versions.

Enis

On Mon, Mar 16, 2015 at 5:46 PM, Devaraj Das <[email protected]> wrote:

> Sounds good to me.
>
> ________________________________________
> From: Enis Söztutar <[email protected]>
> Sent: Monday, March 16, 2015 3:44 PM
> To: [email protected]
> Subject: [DISCUSS] Phoenix supporting HBase-0.98 and HBase-1.x releases
>
> Hi,
>
> As some of you already know, there are discussions in multiple threads in
> the private list, and in jira PHOENIX-1642 about what we should do to
> support HBase-1.0 release and beyond.
>
> Previous discussions resulted in agreement that nobody wants to maintain a
> shim layer for supporting HBase-0.98 and HBase-1.x releases simultaneously.
> It would be hard between 0.98 and 1.x series, but relatively easier (I
> think) to do that between 1.x releases.
>
> Previous arguments also were in favor of not correlating Phoenix
> major/minor versions with the HBase's versions. This means that we do not
> want 4.x to only work with 0.98, and 5.x to only work with 1.x. It would be
> most flexible if 4.4, 4.5 and 5.0 releases work with different HBase
> versions (although 5.0 is under discussion).
>
> Without shim layer and major version based scheme, the only remaining
> option is to have different branches corresponding to HBase-0.98 and
> HBase-1.0. Since Phoenix already has 4.x branch and master branch, the
> proposal is to have 5 active working branches for now:
>
> Branch: master               => This will be main dev branch. 5 series will
> be released from a fork (5.x) from this branch. Will only compile with
> HBase-1.x.
> Branch: 4.x-HBase-1.0   => This will be main dev branch for 4.x series.
> Will work with HBase 1.
> Branch: 4.x-HBase-0.98 => This will be main dev branch for 4.x series. Will
> work with HBase 0.98.
> Branch-4.4-HBase-1.0   => This will be maintenance branch for 4.4.x
> releases.  Will be forked from 4.x before the 4.4.0 release.
> Branch-4.4-HBase-0.98 => This will be maintenance branch for 4.4.x
> releases.
>
> As James points out in the private list thread, we will have 5 active
> branches similar to the previous case where 4.2 and 3.2 were both active.
> Quoting:
>
> > Agreed - that's how we've worked in the past with a 4.2 branch and a
> > 3.2 branch, etc. We've only done patch releases out of the latest
> > minor release branch, so it's not too bad. There's typically 5 active
> > branches: master, latest 4.x minor branch, the 4.x branch, latest 3.x
> > minor branch, and the 3.x branch. This would stay the same (in terms
> > of the # of branches we're actively working in) - it's the names may
> > change.
>
>
> Branch-4.4's should only be created before the 4.4.0 release.
> 4.4.0-HBase-0.98 and 4.4.0-HBase-1.0 releases will be made from those
> branches.
>
> For upcoming HBase-1.1, we can defer that for now until the release comes
> out. I think we may be able to support 1.0 and 1.1 with a very thin shim
> layer, but again that is for another day.
>
> Lastly, there was some discussion whether we want 5.0.0 release supporting
> 0.98. Currently master is 5.0.0-SNAPSHOT and does not have PHOENIX-1642. As
> suggested by Devaraj offline, we can also defer the discussion until the
> time when we want to have 5.0 release. We can commit PHOENIX-1642 to master
> for now, and if we want to support 0.98 in 5.0, we can then revert the
> patch after we have created the corresponding branch if needed.
>
> Let me know what you guys think. Does this sound reasonable, and a thing we
> can maintain? I am up for doing the branching work, but we want to reach an
> agreement first.
>
> Enis
>

Reply via email to