I am not sure. It needs commitment and some good deal of management to keep a release branch like that for features and tracking what went where and ensuring things went into proper releases and not missed. Hadoop has that because they work on some big features which take a long time. What other projects like Pig, Hive, Tez, etc do is maintain a separate branch for those and merge them when that work is ready and more stable. For eg: Pig had separate branches for Tez, Spark, mavenization. Same with Hive. Tez had separate one for UI. This model enables faster development, but the responsibility falls on the folks who maintain the branch and develop on those to stabilize that and ensure proper merge to trunk. We even did that with Hcat integration for Oozie. With the other model, everyone needs to ensure they are checking in more than one branch and it gets slightly complicated. Also it takes away the motivation to keep the trunk in a highly stable state and would be a more time consuming exercise to make it stable if we don't stabilize it often enough by branching from it. Just my two cents bases on my experience with other projects.
Regards, Rohini On Fri, Jan 30, 2015 at 5:57 PM, Robert Kanter <[email protected]> wrote: > Hi all, > > Based on some of the recent large changes to the build and some issues > there, I wonder if it might be a good idea to adopt a branching model like > Hadoop does. They have separate "branch-2" and "trunk" branches so that > things can be committed that should not go into a Hadoop 2.x release can be > committed to trunk and make it into Hadoop 3.x. Perhaps we should do > something similar? > > > - A new "branch-4" that is the dev branch for Oozie 4.x > - Version 4.2.0-SNAPSHOT > - When it's time to do Oozie 4.2, we make a new "branch-4.2" based on > "branch-4" and change the version of "branch-4" to 4.3.0-SNAPSHOT > - The "master" (trunk) branch can serve as a place for longer term > commits that would wait for Oozie 5.x > - Version 5.0.0-SNAPSHOT > > The only difference in committing patches is that you'd commit them to > "master" first, and if it's also meant for Oozie 4, cherry-pick that back > to "branch-4" too. > > Otherwise, we've recently been just taking the current "master" branch and > making it the next Oozie release, which I'm not sure is the best strategy. > > A good candidate for this would be a patch that drops Hadoop 1 and 0.23 > (using only Hadoop 2). That's probably something for Oozie 5.0, but > there's nowhere to put that for now. > > thoughts? > > - Robert >
