If we are in an impasse, then lesser branches to manage is better :-) -Sumit ________________________________________ From: Josh Elser <[email protected]> Sent: Wednesday, January 28, 2015 3:12 PM To: [email protected] Subject: Re: updating the release process; what to do about branches
Totally agree. Pretty much comes down to what do we think a user will want by default like you said. Will they want a specific tag from a release, the branch for some long-lived version, or the "latest"? I think both have merit (I can't really say I see a "stable" master more frequently than a "latest" master or vice versa). Just need to decide what we'd like :) Sumit Mohanty wrote: > 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. >> > > >
