> > 1. a James releasse scenario - this is where you referencing > relased jars > > 2. a James build that is based on the current CVS of Avalon > based on Gump > > I agree with 1, but not with 2. > > I don't think it does James any good to treat the Avalon jar > dependencies any different than we would other libraries. I also don't > think it does Avalon any good in the long term.
I agree with Serge, despite our close relationship with avalon I think we *must* work with released software only, working against cvs risks avalon issues blocking James releases. Of course that doesn't mean we can't or won't be aware of avalon progress, for instance I'd quite like to get the class path stuff Peter D. wrote into James, but not if that would mean James couldn't be released until avalon released, and I would very much rather not sanction a release containing un-released avalon code. In the meantime I'm rolling my own classpath configurations. So my message is release often, I'd rather see a lot of small dependancies advancing in short steps, asynchronously, from stable state to stable state and with corresonding small deltas. That would make the job of upgrading James so much simpler. > These software development practices allow the software engineering to > happen with less restrictions. For the Avalon community, having James > build against Avalon and have Avalon committers help James with that is > a misdirection of resources (IMHO). You will get James working on it, > but at the expense of other activities that can slow adoption of the > codebase (which ultimately James needs to see happen as well). I agree with this as well, I know it seems odd that Serge and I would rather not see everyone bend over backwards to make James work with avalon's latest, but I honestly believe that if avalon are pursuing stabilisation then that process, and the documentation it generates, will, and should be, be enough to help James catch up. > So, I think Avalon should be treated just like other dependencies... > people can propose updates, the community reviews it, and then if > approved, the update happens. Again, yes. d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
