Noel, When you say "fork" do you mean "create a branch in CVS" (per Chapter 5 of CVS manual)? If so, I disagree with you and Danny.
Surely we create a branch (in CVS) after we have a bug-fix to an existing release? At least, that's my understanding of the CVS docs. In which case, discussion of to branch or not to branch can be deferred until we have the next release and a critical bug (ie one requiring a bug-fix release). All that we need to do now is to make the new release and tag the release in CVS. Charles Noel J. Bergman wrote: >If we fork it, and find that we don't have time, we've lost nothing. If we >don't create the fork, and find a need to issue some critical bug fix(es), >then we've got a bigger problem. Seems the prudent thing to do, especially >since it sounds like the next release cycle may introduce compatibility >issues due to API changes. > > --- Noel > >-----Original Message----- >From: Danny Angus [mailto:[EMAIL PROTECTED]] >Sent: Sunday, October 13, 2002 12:33 > >We've never maintained a branch for a release before, I don't think we have >the resources. >I really can't see that we have enough time to maintain two different >versions of James, though the principle is reasonable of itself. >Its my view that we should tag the release, and address bug fixes in the >next release cycle. > >d. > > > >>-----Original Message----- >>From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] >>Sent: 12 October 2002 23:30 >> >> >> >>>There is no reason to fork the code if its going to evolve. >>> >>> >>The reason for forking is simply to be able to put out fixes to >>the 2.1 code based after we make major API changes. If you have >>an alternative that permits both, great. >> >> --- Noel >> >> > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
