Hi, My two cents: If developers need to submit their changes into two branches, then I would vote to hold of another couple of weeks, as Roberta mentions. If we can do a wholesale merge of 1.2.0 into the new hbase1.0 distro, then splitting now would be fine.
Thanks, Hans On Wed, Oct 7, 2015 at 10:40 AM, Roberta Marton <[email protected]> wrote: > Realistically, it will take another couple of weeks to put all the pieces > together and release our first tarball to the test site for release 1.2.0. > After we get the source released, it may be a couple of more weeks to get > it > through the Apache process. > But, if everything thing goes like clockwork, it could be less time. > > Roberta > > -----Original Message----- > From: Dave Birdsall [mailto:[email protected]] > Sent: Wednesday, October 7, 2015 10:23 AM > To: [email protected] > Subject: RE: Start another branch for HBase 1.0 support > > What is the proposed timing? > > -----Original Message----- > From: Steve Varnau [mailto:[email protected]] > Sent: Wednesday, October 7, 2015 10:15 AM > To: [email protected] > Subject: Start another branch for HBase 1.0 support > > Trafodion Developers, > > > > We are working toward our first release (1.2) under Incubator project. > Meanwhile, folks are starting work on supporting HBase 1.x for future > release. So I’d like to propose we start another branch to support both > lines of work. > > > > If we do that, it does imply some extra overhead for changes that apply to > both lines of work. Each developer will have to submit change to each > branch, or someone will need to occasionally merge all the 1.2 work > forward. > Given that each developer would know their change-set the best they should > be the ones to submit it to each branch. > > > > **Given that overhead, do you agree that it is time to start another > branch?** > > > > Strategy we’ve used in past is to put the imminent release on a side branch > (e.g., stable/1.2) that can be used to stabilize code for release and for > any post-release patches. Which would allow new feature development to > continue on master branch. > > > > If majority of changes are still going to be aimed for 1.2 release for some > time to come, we could keep 1.2 on master branch and have a temporary > feature branch for hbase1.0, but my proposal is to go ahead to create > stable/1.2 and allow next release work to come into master branch. > > > > **Do you agree to create stable/1.2, and open master branch for net release > features?** > > > > Let me know what you think. I’ll work on setting up build & test automation > to support two branches. > > > > --Steve >
