> 1. I'd like to hear more of the case for upgrading our Avalon components.
Hopefully, Stephen can give us a better overview, but here are some
observations:
a) there are bugs in Avalon code, and currently the only
way to get the fixes is to upgrade our components.
b) there are other Avalon containers, and if we want
James to be able to run in them, as Stephen is
attempting to do, then we need to support the
current interfaces.
> we've got an underlying library that changes API and features,
> sometimes without changing version numbers, so without listing
> the benefits, it's the kind of upgrade I generally think a lot
> about before doing.
Yes, I know. They haven't even updated their site documentation to list the
changes, so I would have to pull a CVS log and hope that they are commented.
Which is why I wouldn't even consider changing James v2. But I think that
it makes sense for James v3.
I don't believe that we don't want to be trapped with code that we can't get
bug fixes for, and can't even properly identify the source.
> 2. I don't think whoever is making these changes should commit changes
until
> you have a runnable James
There might be multiple people making those changes, unless Stephen already
has them made. (Peter has, too, so I might be able to get them from him,
but I'd need to refit to James).
> 3. I don't think we need to branch as these changes could be made directly
> to HEAD.
If we can make them in one swoop, without problem, then I agree. I just
want to be safe. I suppose that we could be safe by tagging first, and then
see what happens.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
