Agree that master will serve a purpose. develop may go through bouts of "being temporarily in bad state" due to live coding.
The question is will a user, wanting to use the latest, prefer 1) the master branch that can get updated upon release (can be a surprise if you do a git pull) 2) the latest release branch but they need to explicitly move to the newer releases IMO, later is better as user controls when they move to newer releases. Presumably they are using a branch (master or otherwise) because they want to compile the binaries themselves. That said, we can look at other projects for typical patterns. -Sumit On Wed, Jan 28, 2015 at 12:39 PM, Gour Saha <[email protected]> wrote: > The most common use I have seen for the master branch, is to signify that > it contains the most recent release of the product. The individual release > branches would still be there, like releases/slider-0.60, > releases/slider-0.70, etc. But for anyone who would just need the latest > release would not have to look around to find the latest branch or tag. > They would just checkout master. Very old release branches can be purged > from time to time. > > *A typical project lifecycle from branching point of view could be > something like this -* > Development happens in develop branch. There would typically be bunch of > features developed in specific feature branches, and they would be merged > into develop. A release branch is then created off of develop when the code > freeze date for a specific release is reached. From then on typically only > bug fixes are taken into the release branch based on QE find. The develop > branch is open at this point for regular development for next releases, > etc. Once the release branch is stable and free of must fix bugs, it is > ready to be released. All release work is done off of the release branch. > Once the global announcement is made and binaries are released to the world > the master branch is synced with this latest release branch. > > This document provides more details and is used by quite a few companies > for internal development - > http://nvie.com/posts/a-successful-git-branching-model/ > > Thoughts and comments on this strategy? > > -Gour > > > On Wed, Jan 28, 2015 at 10:02 AM, Josh Elser <[email protected]> wrote: > > > 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. > >>> > >>> > >> > >> > >> > > -- > 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. > -- thanks Sumit
