On Tue, May 05, 2015 at 02:50PM, York, Brennon wrote: > 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.
I thought the diagram I've sent was pretty clear, but here's a description of it. Everything is done on branches: hotfixes, feature development and releases (after all git branches are free). Now, if you need to issue a fix for an older release you as the workflow suggests: - cut a branch for the hotfix (let's call it HF-branch) most likelt off the release branch - do usual CI on it - merge HF-branch into master and the release branch in question - do the rest of the work on the release branch: bump the version, etc. - delete HF-branch Does it make sense? Cos > 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.
