I would favor the current mapping - a little more intuitive IMHO On Jan 29, 2015, at 5:40 AM, Steve Loughran <[email protected]> wrote:
> > (apologies for any formatting confusion here; I am migrating to Outlook web > apps) > > > I quite like the git flow bit of the sourcetree GUI; it looks like we can > change the policy here for it to make the "master" branch the one git flow > branches from/merges with, "master" could be "release" -and ignored if we > don't use that aspect of the git flow process > > [gitflow "branch"] > master = master > develop = develop > > ________________________________________ > From: Josh Elser <[email protected]> > Sent: 28 January 2015 18:02 > To: [email protected] > Subject: Re: updating the release process; what to do about branches > > Could also just remove "master" in its current use and > s/develop/master/, leveraging the master branch as the normal place > things are implemented. > > It really doesn't matter in the end (it's just a name), but, if this is > also signifying a move away from git-flow, it makes more sense to me to > use "master" instead of "develop". > > > Sumit Mohanty wrote: >> I vote for removing the master branch. This is in the line of what I was >> also wondering since we have created branches for 0.60 and 0.70. Branches >> can remain the source of truth for the release and can facilitate minor >> releases if needed. >> >> On Wed, Jan 28, 2015 at 8:58 AM, Steve Loughran<[email protected]> >> wrote: >> >>> The latest release process document is now in svn at >>> site/trunk/content/developing/releasing.md >>> >>> It hasn't yet propagated to the HTML view, when it does it will be at >>> >>> http://slider.incubator.apache.org/developing/releasing.html >>> >>> I think we've outgrown the git flow release process. >>> >>> The feature branch seems to work well, but the release process has >>> everything merged into the branch "master", >>> >>> - It doesn't handle long-lived release/supported branches >>> - Merging into master/ can create convoluted dependency graphs, >>> resulting a commit graph (and hence git commit ID) which is different >>> from >>> what is released. >>> >>> What are we to do? >>> >>> I'm wondering if we should get rid of that master/ branch altogether. >>> >>> Instead we could have some tags which we could move around: >>> >>> - last_branch_6_stable_release >>> - last_branch_6_dev_release >>> - last_branch_7_stable_release >>> - last_branch_7_dev_release >>> - last_stable_release >>> - last_dev_release >>> >>> If you fetch all tags then check out by tag, you end with whatever version >>> we think is "last" on a branch; the stable/dev releases can even cross >>> branches as something migrates from development to stable >>> >>> During the release process, instead of doing git merge master work, we'd >>> just delete some tags, create the new ones and then push them to the >>> origin. >>> >>> Thoughts? >>> >>> -steve >>> >>> -- >>> CONFIDENTIALITY NOTICE >>> NOTICE: This message is intended for the use of the individual or entity to >>> which it is addressed and may contain information that is confidential, >>> privileged and exempt from disclosure under applicable law. If the reader >>> of this message is not the intended recipient, you are hereby notified that >>> any printing, copying, dissemination, distribution, disclosure or >>> forwarding of this communication is strictly prohibited. If you have >>> received this communication in error, please contact the sender immediately >>> and delete it from your system. Thank You. >>> >> >> >>
