Why don't we do both? It is more important to develope a model for 4.1 and continue enhance that where it is required. We can always keep a Framework5 revolution in mind but I think that will fall out of things we do for Framework4.x. ie As we find uglies in Framework4.x we add them to a list of things that we should fix in Framework5.x and if by the time 4.x is finished the list is big enough we move to Framework5.x
On Tue, 3 Dec 2002 03:36, Berin Loritsch wrote: > This is a vote to clarify whether we want to focus all > our discussions of the new unified container to Avalon 5 > (next generation) or Avalon 4.1 (current generation). > Here are the implications: > > Avalon 4.1 > ---------- > Current development. We refine current interfaces so that > the contracts are more universal and testable. This includes > the semantics we have surrounding Context and Serviceable. > It also means that we can't clean up the cruft. (deprecated > stuff remains deprecated). > > Avalon 5 > -------- > New development/clean slate. We leverage our experience with > lifecycle interfaces to provide a starting point, but we do > not limit ourselves to that alone. We can clean up the cruft, > but we must supply a "Compatibility JAR" to allow easy migration > from Avalon 4.1 to Avalon 5. We can also shorten the package > names (minor, but sometimes helpful). It also helps us unify > on a new product. > > If we continue version 4.1 development we don't have the > luxury of challenging any of the current lifecycle interfaces > or making things just simply easier to use. > > Implied in either action is that the existing containers continue > to live their lives until the new container is complete. > > > Which is it? Unified Container == Avalon 4.1 or Avalon 5? > > > (Voting to remain open as long as necessary [not less than a > week]). > > Please provide a quick comment why you made your choice (either > way). -- Cheers, Peter Donald *------------------------------------------------* | The student who is never required to do what | | he cannot do never does what he can do. | | - John Stuart Mill | *------------------------------------------------* -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
