[LLVMdev] Project Release Branches

[John Criswell]

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.

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.

-- John T.