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
