> Perhaps a better approach to this might be to kick off an experimental > james branch where we can do the required refactoring without worrying > too much about breaking things and hindering current james development? > Or, if you think that they might have a more stable API in a few > months, maybe the sync up should wait for james v4?
Personally I'm inclined to think that once we find satisfactory avalon bits we may as well stick with them until there are signs of real stability, real bugs, or real improvements, rather than chase our tails just to keep up. It has taken until now for us to be able to move to a stable release of phoenix, one didn't exist before, and we cant in good concience release james on alpha and beta versions of major dependancies without issuing caveats to our users. If other avalon things (I hesitate to use specific terms incorrectly) have a long cycle that ends up with a stable version which has a large delta over the previous stable, then we are going to ask ourselves what we gain in return for the cost of refactoring and whether the same situation will occur in the next cycle. I'm *not* slagging off avalon or any of the avalon contributors, who are nice, supportive and smart, but I'm not going to pretend we're all always happy with their progress or direction just to perpetuate the idea of a happy apache-java-server domain, I think I'm taking a pragmatic approach, and one that other consumers and potential consumers of avalon will also share. I think that probably sums up my attitude, I'd really like James to be able to be nothing more than a consumer of avalon, and I'm sure we'd provide plenty of feedback and cross-fertilisation. The problem is that we end up having to be a test-bed, and James commiters have to get their hands dirty in the avalon codebase if we want to keep abreast. > > At the end of the day, what is the point of using Avalon at all This is a question we ask ourselves monthly. > if we > are going to be stuck with an obsolete version forever? The benefits of > not having to re-invent the wheel begin to pale very rapidly when you > can feel every bump in the road through the steel rims! How did people > ever get by without steel-belted radials and double wish-bone suspension! Thats, if you mean the effort required to ditch avalon, is sometimes the only reason we don't. I'm not totally down on avalon, but I would much rather spend my time on making progress than shuffling things round because of dependancies. As far as the specific case is concerned, there is merit in updating James, and the head is the place to do it, but we should try to gauge the scale of the problem before we cut code. Finally I think that if avalon people want to look at James they can patch our current code, or fork a copy into their own repositories, I can't see the benefit of creating a branch which will be adapted to avalon's latest, if we then have to migrate all those changes to the ever evolving head. d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
