On Tue, May 05, 2015 at 12:41PM, York, Brennon wrote: > I’m in favor of setting a branch for each release (e.g. ‘branch-0.5’). For > reference its what many other projects do in ASF (e.g. Spark, Hadoop).
>From first hand experience: unfortunately Hadoop is using SVN branching model on git. And it is getting _very_ time consuming when you're dealing with 2+ more release trains. Eg in case of Hadoop 3.x (trunk) and 2.x branches. That's pretty unfortunate they never adopted the benefits of git. Once of the most troublesome outcomes of it is a need to either cherry-pick commits from trunk or do multiple commits for each patch. Argh... The biggest plus-side of the model I am referring, is that you have _all_ you code on the master because feature branches are merged into it and got deleted; and long-lived release branches are merged into master periodically with tagging. As the result, you preserve the history of the changes, because merges preserve commits SHA1. And you have non-material tags that allow you to branch out later if you need to have a hot-fix for an older release or something. > I’ve personally seen it help to maintain feature sets per branch, back > porting bugs into older versions, and, in the long run, help maintain > production support for various versions. Actually, it is not - see above ;) Cos > > My 2c :) > > On 5/5/15, 1:58 AM, "moon soo Lee" <[email protected]> wrote: > > >Hi Cos, > > > >Thanks for useful information. I think we're in the same page. > > > >The branch i'm suggesting ('branch-0.5') is considered as a release > >branch, > >while we do stabilize code and make a release from the branch. > > > >Zeppelin receives patch via pullrequest and it is looks like pullrequest > >is > >feature branch. > > > >I was thinking managing branch 'master' as a dev branch and maintaining > >master source tree by creating tags. Not a branch. This is a difference > >from the link. > > > >Any thoughts? > > > >Thanks, > >moon > > > >On 2015년 5월 5일 (화) at 오후 2:25 Konstantin Boudnik <[email protected]> wrote: > > > >> One of my long time favorite git branching models and one that is really > >> working > >> http://nvie.com/posts/a-successful-git-branching-model/ > >> > >> Perhaps something to consider? > >> Cos > >> > >> On Tue, May 05, 2015 at 01:56PM, Alex wrote: > >> > Hi, > >> > > >> > I like the idea of really simple git workflow with only one branch so > >> there > >> > is no questions like where to merge things to? Which branch to build > >> from? > >> > Which is latest, which is stable etc.. > >> > > >> > Because all this requires human interaction to resolve. > >> > > >> > But at the same time if you think that having multiple branches witch > >> are up > >> > to date and documented well will solve the problem of > >>stability/faster PR > >> > merge time - I think it might be worth giving it a try, say for next > >>3 > >> > months, and see if that helps. > >> > > >> > > >> > -- > >> > Kind regards, > >> > Alexander > >> > > >> > > On 05 May 2015, at 11:22, moon soo Lee <[email protected]> wrote: > >> > > > >> > > Hi, > >> > > > >> > > I'd like discuss about creating a branch(ZEPPELIN-67 > >> > > <https://issues.apache.org/jira/browse/ZEPPELIN-67>). > >> > > > >> > > Currently, building source from master branch is the only official > >>way > >> user > >> > > can use Zeppelin. Therefore, we're extremely careful when merging > >>code > >> into > >> > > master and that slows down development. > >> > > > >> > > If we make a branch and keep the branch stable, so user can build > >> Zeppelin > >> > > from it and make a release from it. That'll help both keeping code > >> stable > >> > > and faster accepting pullrequests. > >> > > > >> > > What do you guys think? > >> > > > >> > > Thanks, > >> > > moon > >> > > ________________________________________________________ > > The information contained in this e-mail is confidential and/or proprietary > to Capital One and/or its affiliates. The information transmitted herewith is > intended only for use by the individual or entity to which it is addressed. > If the reader of this message is not the intended recipient, you are hereby > notified that any review, retransmission, dissemination, distribution, > copying or other use of, or taking of any action in reliance upon this > information is strictly prohibited. If you have received this communication > in error, please contact the sender and delete the material from your > computer.
