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]>
