> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED] > > On the other hand, things must continue to go forward, and > things that > obviously don't work must be rectified and changed. > > Avalon has still in minds of many a bad name about the heavy > refactorings it did years ago. Avalon is stable, works well, > but still > developers remember what happened back then. I don't want > this to repeat. > > So this is my opinion: let's go for *AValon* (V==5). > > *BUT* > > Let's build on 4.1. That means *not* change packagenames, > *not* change > class names just for the sake of it, *not* create new classes > when the > existing ones can do with proper deprecation.
Essentially you want Framework 4.2 That's fine, but you aren't looking to get rid of the already deprecated stuff, or clean up how some things work. > Let's bring out our issues and visions, understand what users > need and > we want; then take 4.1, package per package, discuss them, > see what can > be taken - and I'm sure it's most of it - and make AValon. That's how I would do Avalon 5, but keep in mind where we were back when we first discussed the idea of Avalon 5. For instance we had ComponentLocator (no release method because the container was supposed to be able to intelligently pool behind the scenes), and a couple of other things. That would mean YADP (Yet Another Deprecated Package). After a while it gets rather heavy. Let's be clear though, Framework 5 is a clean slate, Framework 4.2 is an evolutionary approach. It seems that there are several of us who want the 4.2 approach--which is not necessarily bad, but there are certain things we cannot do yet. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
