[LLVMdev] Project Release Branches

[Chris Lattner]

On Nov 13, 2012, at 9:29 PM, John Criswell <criswell at illinois.edu> wrote:

> On 11/13/12 12:37 PM, Chris Lattner wrote:
>> On Nov 13, 2012, at 7:52 AM, John Criswell <criswell at illinois.edu> wrote:
>> 
>>>>  John, it was not my intention to disrupt your work in any way.
>>>> However, branching for release is a bit of a grey area and I
>>>> have made a judgment call to branch SAFECode in sync with llvm.
>>>> This could have been a bit overzealous but I am used to
>>>> "release at any time" approach or agile project management.
>>>> 
>>>>  Since LLVM/Clang has grown so much I think the release process
>>>> will require some adjustment to keep up with the sheer size of it.
>>>> From my experience it is hard to make progress without accepting
>>>> changes while at the same time making changes usually leads to
>>>> some unintentional breakages.
>>> Okay.  Just know that SAFECode is undergoing evaluation by one of our funding agencies.  There have been and will be times in which we can't tolerate breakage.  Fortunately, the next evaluation is about 12 months away, IIRC.
>> Why not make a "release" branch for these sorts of things?
> 
> Chris, can you clarify what you are suggesting?  Your statement is sufficiently ambiguous that it could mean one of several things.

I'm suggesting that you could change your development approach so that mainline safecode always follows mainline llvm, and that you do a majority of your work on branches.

> Just so that everyone knows, SAFECode branching and development works a little differently than LLVM.  With LLVM, nearly all development happens on the trunk, and then branches are created for each release.  Changes are selectively folded into the release branch until the release is blessed, and then (generally speaking) the release branch isn't touched again.
> 
> SAFECode works differently.  With SAFECode, there is a release_xx branch for each release of LLVM that we support.  For example, the SAFECode release_30 branch works with the release_30 branch of LLVM.  The idea is to make it easy for people to grab updates to SAFECode that work with a particular LLVM version.
> 
> The real difference is that SAFECode usually sticks with a single release of LLVM for awhile, so while LLVM is developed on trunk, we often develop SAFECode on the branches.  When we decide to start following mainline LLVM again (e.g., because we want to work with the upcoming next release of LLVM), we first merge the release branch changes back to SAFECode trunk, update SAFECode trunk to work with LLVM trunk, and then track LLVM trunk until the next release. When the next release of LLVM is made, we make a corresponding release branch and continue development there.
> 
> Note that the merges here are usually conflict free.  When a SAFECode branch is made, development stops on SAFECode trunk until we're ready to start chasing LLVM mainline again.
> 
> With this process, having a person who isn't doing SAFECode development creating release branches is problematic.  This person may create a release branch before changes from the previous release branch have been folded into trunk or create a release branch for a version of LLVM that we don't even support.
> 
> While SAFECode's branching behavior is different, I think it's logical, simple, and effective.  However, since it's different, I'd rather handle the branching myself or, at the very least, have the release manager talk to me about what I need.


You're describing the old LLDB development model (with the absence of "llvm.zip" :).  It has a number of problems: 1) it discourages community contribution, 2) it makes it difficult to set up a buildbot, 3) it is different than everything else in the project.  

I don't have a strong opinion - you can do what you want, just saying that there are other options.

-Chris