We had good discussions and i can see at least we need release branch. I'd like to proceed creating 'branch-0.5' as a release branch. Once it is created from current master, Pullrequests are going to merge into master branch only. If there're some fix to be applied to branch-0.5, it will be merged into both master and branch-0.5 branch. (our merge tool already support it).
Target branch for the pullrequest can be marked as a 'fix version' in related jira issue or explicitly say in a pullrequest's comment. Otherwise, will be merged into master branch only. Once we have 'branch-0.5' we can try release from it. I'm creating a branch in next 24 hours if there're no possible serious downside. Best, moon On Wed, May 6, 2015 at 5:37 AM moon soo Lee <[email protected]> wrote: > 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. >> >
