> Hmm,I really hope you are right. > > But if you look at the history of Avalon, the dramatic changes from > (was it 2.x or) 3.x to 4.0 which was really a nightmare for real users > of Avalon and now again (not so) dramatic changes from 4.x to 5.0, > I guess many people will fear that there will also be dramatic changes > in the future from 5.x to 6.0 and so on. > So why should I use such a rapid moving target? How can I develop tools > for it if my tools are out of date with the next release? And so on. > This might happen or might not, who knows? But I know that this has > happened in the past.
I think you should take into account avalon was "alpha" until 4.0, and large parts of it still are (cornerstone, phoenix, apps). That status is intended as a clear message to users "there will be dramatic changes ahead". This is not the case for avalon framework. I anticipate an avalon framework 4.2 (4.1 has no issues, so I don't think there'll be more releases of that one) with some new features (like interfaces defining metainfo), maybe a 4.3, then a 4.5 (with realy new stuff like a SEDA implementation), all of which will be binary backwards compatible. Whether avalon framework 5 will be fully binary backwards compatible or not has not been decided on yet, but I think it will be, even if it will be through a "compatibility mode". Still, it is quite a bit off in the future. All this to assure that the current avalon framework 4.x is not a rapid moving target. You might further find http://www.mail-archive.com/avalon-phoenix-dev%40jakarta.apache.org/msg00390.html to be of interest. - Leo Simons -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
