> > 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.
More about Excalibur himself (see the logger package of 4.1, LogKitManager is deprecated but not LogKitManageable) and Excalibur with Framework, "Developping with Avalon...". > > 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. It's what I wrote a project with dependency on Avalon... do the choice of the version and how/when it upgardes. I wrote that differents strategies have differents risks. And a nightly build doesn't have stable API. > > 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. Which users ? Not the users of a "released" version. Users of the nightly want to be uptodate and use the last recommendations or concepts and are OK to pay the price. But newbies who read the last api and framework are confused by the mixe of informations. By exemple in a other project I use Cocoon, I want my team study Avalon to understand better Cocoon, but I can't, because the management of Log is different. I think there is a probleme in the targetted audience. > 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. No, actually with 4.1, a developper can't build a application without deprecated warning like you wrote. I think "apply deprecated API recursively" help to find deprecation without remove them, and help to find where alternatives are necessary. > > > - 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. Why not set a new branch or use a compat lib. Why a project want the last version ? > > - 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. It's possible to provide a guide to help migration with users experiences. > > - 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. When I spoke about the nightly version, I meant the current development version with the future documentation. Like I say, it's very confusing to have some documentation say use that in one page and use this in other page. > > 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. OK, i 'll take a look. Regards, PS: Sorry for raise alarme about ECM... -- -------------------------------------------------------------- David "Dwayne" Bernard Freelance Developer (Java) mailto:[EMAIL PROTECTED] \|/ http://dwayne.java-fan.com --o0O @.@ O0o------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
