David BERNARD wrote: > Hi, > > I've studied Avalon family in september 2001, and I can't use it in > project due to api coherence. After some time I want to used it again > because there official "release" and documentation have been updated, > and I think avalon is very good (philosophy, approch...). > But in a "release", there are again incoherence : > - incoherence between documentation and released api, > - from scratch application need to use deprecated classes or methods > like ECM.
Could you go into more detail of what *exactly* you are driving at with API coherency? Give me a specific definition so that we are on the same page. From the bits and pieces, I have put together, Framework itself is API coherent--your concerns arise in Excalibur. > > Why ? > > * backwards compatibility, like wrote Berin (2002/02/08) : > > >>The Loggable interface is freshly deprecated, we cannot simply drop it >>from the face of the earth. >> >>ExcaliburComponentManager and friends are *not* deprecated. >>Using them will definitely cause deprecation warnings in the interim, >>but that is the price to pay for backwards compatibility. > > > I'm not OK. If a developper use : > - a released version : backwards compatibility is need if he wants > to upgrade. And he wants to upgrade for : > - used new features then he is potentialy alright to update his code. > (no need of backwards compatibility, it's the price of the update) > - updated libraries dependancy to be ok with runtime context. > - bug fixes, but in this case when he find a bug, > he doesn't know when fixe will be published or released so he code > himself the patch, use other librairies or extract new version > of the classes in the CVS tree. > (no need of backwards compatibility, it's the price of the update) > - a nightly version : > - he used a specified version, he use it like a "release" one. > - he updates periodicly, then he knows that api are unstable. > (no need of backwards compatibility) > > So the need of backwards compatibility, isn't a hight priority. And It's > dangerous for new project, see the M$ Windows experience. For the moment > there aren't lot of application based on Avalon/Excalibur but new > project team can be frightened by the obligation to use deprecated api > like ECM. You'd be surprised at how many projects use Avalon--even within Apache. We don't want to be in the business of manually upgrading the projects when we deprecate something. We would rather give the projects time to migrate themselves--when they are ready. A project is not always in a position to upgrade his code overnight. Too many upgrades and we scare of other projects. We have already been down that road. With Avalon Framework 4.0 we drew a line in the sand saying that this API is supported. We must support it. >>I am still working on the replacement technology >>I am alot closer than I was, but still not all the way there yet. >>Once done with the ContainerManager and friends, if we are happy with >>that, we can talk about deprecating the ECM and friends. > > > Then my conclusion, he is you loose interested user of the avalon. > Because newbies developper or new project can't find a coherent api in > "released" version (librairies + documentation). > I suggest : > - to release more often (minor or macro) version. I am in favor of releasing more often. We do need to finish our restructuring of the Excalibur build before we can make that release happen. > - to apply depredecated api recursively > (if a method uses a deprecated Class the it's deprecated) In the case of ECM, I *could* have forced the upgrade, but then users who had an investment in Loggable components would be left high and dry. Instead we provide compatibility for the deprecated Loggables so that when the other projects get up to speed, they don't have to change CM infrastructures. > - to provide alternatives to all deprecated api. We have those alternatives in place. > - to remove deprecated api every 2 or 3 minor release. That is not an option. Some projects take longer than 6 months to upgrade. While we have some cruft in our systems, it is not unmanageable. We need to give at least 6 months to a year. > - to have 2 sites (librairies + documentation(changes, api, tutorials, > overviews...)) : > - site for "Release version", where you can add an API changes > rubrique (see JDiff http://jdiff.sf.net) whith the diff between > succesives releases We are moving toward this approach. > - site for "nightly version", where you have access to cvs, > nightly snapshot, new documentation, proposed orientation... Nightly CVS snapshots are generated by Apache. It *only* takes care of the tarball. We cannot maintain such a vision without automated tools. We are in the process of automating the site maintenance now. > > PS : I've got some time this month if you want help (to update code or > documentation (in this case I only see mistake, sorry for my english), > ...). > If you want to help update the site docs, feel free. We need to come to consensus on code changes though. We aren't removing anything without a vote. -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
