David BERNARD wrote: >>>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.
Sure, but when we release, we have to have a smooth upgrade path. The backwards compatibility stuff ensures that. It is easier to apply immediately than retrofit after the fact. > Users of the nightly want to be uptodate and use the last > recommendations or concepts and are OK to pay the price. They know the risks, yes. However, our nightlys are a march toward another release. > > 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. They are? that's news to me. > > >> 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 didn't say they wouldn't get deprecation warnings. I said we have alternatives in place. > > 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 ? Good question, but we have had that happen. We do have to live with the realities that the code is used. > > >>>- 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. Sure. > > >>> - 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. Documentation maintenance is a pain, so we tend to put it off. IT's human nature. > Regards, > > PS: Sorry for raise alarme about ECM... IT's ok. -- "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]>
