Carsten Ziegeler wrote:
compatibility. But as Cocoon is distributed as a source release that you have to compile anyway, it's saver to compile your own application code (if
2 thoughts:
- I think this has more to do with the nature of Java, then how we release stuf (i.e. there is no real distinction between compiling versus source or class files AFAICS, that is why we cannot make the distinction the apr blokes are making between source and binary compat, no?)
- I would like us to make binaries again somewhere soon. Apart from the outcome of that discussion I find it odd to use the way we distribute as an argument for anything mentioned here, no?
any) using the version of Cocoon that your application runs on. [ADD SOME REASONS WHY WE RECOMMENT RECOMPILATION ANYWAY]
ONLY ONE AFAICS: - you'll get warned of deprecated parts of the API
and one more suggestion after reading it all
(to be added at the end)
Reality
-------
The above expresses the intentions of the cocoon community to support a release management contract to all the users of the framework. However reality observes that the path to hell is paved with goood intentions. In case anyone finds clear violation of these good intentions he/she should report those to [EMAIL PROTECTED] in order to let proper action be taken. (which might be reverting some changes and/or assigning a different version number)
apart from that,
big +1, and thx for this work, Carsten.
-marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
