[LLVMdev] release tag policy

[John T. Criswell]

Chris Lattner wrote:

>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.
>  
>
Agreed.

>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.
>  
>
Okay.

>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.
>  
>
Switching to another naming convention might be a good idea; it seems 
it's causing confusion.

Since Tanya is the release manager now, I'll defer to her judgement.  If 
you'd like me to draft up the conventions I used, please let me know.

-- John T.

>-Chris
>
>  
>