Nicola, I totally buy Gump's raison-d'etre, In fact I champion domain engineering and continuous integration at work, and see how continuous integration benefits us. But to buy into it for James I'd have to have confidence that changes which are made to support avalon head changes, and which break james for avalon stable packages, will make it into stable avalon packages in reasonable time for us to release the james head more or less when we want to.
d. > -----Original Message----- > From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] > Sent: 24 January 2003 12:52 > To: James Developers List > Subject: Re: Excalibur/Cornerstone/James woes > > > > > Aaron Knauf wrote: > > Yeah, it doesn't help that the Avalon APIs aren't yet stable. > > Which APIs? :-? > > The Framework has been stable for a long time. > > > This is a > > sign of the current lack of maturity in the Avalon codebase. When you > > base your application on such a raw framework, you buy into > this kind of > > trouble. It seems to me, however, that the Avalon guys might > be willing > > to work on stabilizing their interfaces. They are going to find it > > tough going trying to stabilize without close support and feedback from > > their user community, though. (That's us!) > > We are consolidating out *implementations*, not our APIs. And yes, we > would be happy to have close help from you, and that's the reason why we > are defining concrete ways in which the James community can have real > life in ours. > > > Perhaps a better approach to this might be to kick off an experimental > > james branch where we can do the required refactoring without worrying > > too much about breaking things and hindering current james development? > > Or, if you think that they might have a more stable API in a > few months, > > maybe the sync up should wait for james v4? > > The best and *easiest* solution for all is to synch now and keep in > synch via Gump. > > Let's say that we make a change to a Component and that breaks James. In > the possibility that there is an Avalon Component repository, James > developers active there would have a veto on the commit, and it would > help keep things clean. > > > At the end of the day, what is the point of using Avalon at all if we > > are going to be stuck with an obsolete version forever? > > Let's collaborate, and things will go into place. > > -- > Nicola Ken Barozzi [EMAIL PROTECTED] > - verba volant, scripta manent - > (discussions get forgotten, just code remains) > --------------------------------------------------------------------- > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
