Thanks for the feedback. Overall i agree with Cos proposed way. In my experience, keeping master branch (always production ready) as well as development branch sometimes confuses people (eg. when people branching for new feature). And master branch is very easy to end up with being just a reference to latest release tag. That's the reason why i think it's enough to have release tags for production ready code without master branch. And then development branch can use name 'master'. To me, branch name 'master' in git feels more like 'trunk' in svn. I think the name fits more for dev branch.
Best, moon On Tue, May 5, 2015 at 8:16 PM Konstantin Boudnik <[email protected]> wrote: > 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. >
