Cos, can you dive a bit deeper into what you’re proposing? I’ll be the first to admit that I assume there’s a better way to do this than what’s been done previously and I’m trying to understand this new methodology.
My question is honestly purely a question from worry for production support. To dive deeper, how, given this Git style, would one retrofit a bug fix into an older release? From my experience its terribly difficult to get enterprises to bump up versions without tons of internal regression testing, but, oftentimes, there are hot fixes pushed into previously releases (1.3.0 -> 1.3.1 versioning for instance) that will get rolled out quickly (with the bugs typically found from enterprise regression). In short though, if this new way can handle that, I’d love to give it a try! :) On 5/5/15, 11:38 AM, "Konstantin Boudnik" <[email protected]> wrote: >On Tue, May 05, 2015 at 08:58AM, moon soo Lee 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. > >That's a possibility as well. But in this case you might end up with >either > a) a necessity to do multiple merges across all active branches from the > master. This will get very tricky as soon as the branches drift apart >far > enough > b) you will face a need to start cherry-picking, which will ruin the >history > of changes migration across the branches. Remember, cherry-pick is > changing commit hash. > >Does it make sense? > Cos > >> 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.
