Given that log4j 1.3 is not likely to be released before a few months, I have created a branch called v1_2-branch in our CVS repository, by issuing the following command
cvs -d :ext:[EMAIL PROTECTED]:/home/cvs rtag -b -r v1_2final v1_2-branch jakarta-log4j Using the 1.2 branch, we can incorporate patches to log4j version 1.2 while version 1.3 continues to be developed on the main trunk. For example, we can officially release lf5 (including documentation) already in log4j 1.2.1. Brad, does that sound reasonable? To command to access the v1_2-branch is: cvs -d XYZ checkout -r v1_2-branch jakarta-log4j where XYZ is the remote repository name, that is ":ext:[EMAIL PROTECTED]:/home/cvs" for me. Alternatively, you can issue the cvs update -r v1_2-branch command from an existing work copy. Working with branches is not completely trivial and requires a little coordination between committers, in particular in relation with branch merge operations. In order to avoid multiple merge conflicts, each time we merge from the 1.2 branch to the main trunk, we should (must?) tag the merged version on the 1.2 branch. Subsequent merges should use the tag referring to the latest merged version of the branch. Also do not forget to publicly announce a merge operation. If this sounds like mumbo jumbo, I urge you to consult the CVS documentation and experiment with branches before hitting the log4j repository. Branches are not that complicated really although they require slightly more discipline on the part of committers. Do not hesitate to shout if you need help, -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
