[LLVMdev] release tag policy

[Chris Lattner]

On Tue, 13 Feb 2007, John T. Criswell wrote:
>>> I recommend that you stick with the release_19 branch of both llvm and
>>> llvm-poolalloc.  I and others are actively using these branches, so
>>> llvm-poolalloc bug fixes will most likely be made to this branch in
>>> addition to mainline CVS for the forseeable future.  The release_19
>>> branch of llvm-poolalloc is designed to always work with the release_19
>>> branch of LLVM, which has a fixed API and bytecode format.

>> I did not realize that you guys were checking in changes to the release_19
>> branch. I have to disagree with this as release_19 is supposed to match
>> the release 1.9 that we have on our website. This release has been tested

> 1) According to the policy I set forth when I did release management,
> there is a difference between RELEASE_19 and release_19.  RELEASE_19 is
> a tag that denotes what we released in LLVM 1.9; it should never
> change.  The release_19 tag is a branch tag that denotes the branch for
> the 1.9.x releases.  To date, we've only created one release per release
> branch, but we should be able to make subsequent releases on the branch
> (e.g. 1.9.1, 1.9.2, etc) if we want.

I think the real problem here is that the current policy is either not 
documented, or is inadequately documented.  Please pick a policy and stick 
with it, but describe it somewhere in the release guide or in the new 
'Developer Policy' section.

I think having a sub-release branch makes sense for dot releases.

> 3) The only changes in the llvm release_19 branch is the removal of DSA
> and (maybe) some minor autoconf changes.  I did this to ease merges on
> DSA between the release_19 branch and mainline of the llvm-poolalloc CVS
> module.

Regardless of the policy, I don't think this is acceptable.  Your stated 
goal for the release_19 branch is for it to be a host for 1.9.1.  Removing 
an entire library does not sound like a ".1" change.  If you wanted to do 
this, having a separate branch would make sense, instead of taking over 
the 'release' branch.

I don't care about correcting this for the 1.9 release, and I don't really 
think that overloading RELEASE_19 and release_19 is a good idea, but 
please work together and figure out a policy that makes sense.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/