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 > > >
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/
On Tue, 13 Feb 2007, John T. Criswell wrote:>> 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.I agree.> 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.I propose that Tanya write up a summary of the 'rules' and pick a naming convention, sending it to this list. That way she can get feedback from you (and others) and the wording can be folded into the new Developer Policy doc. Sound reasonable Tanya? Isn't it great that LLVM is growing to the point where people care about these things? :) -Chris -- http://nondot.org/sabre/ http://llvm.org/