Guido Casper wrote:
Unico Hommes wrote:
Guido Casper wrote:
Guido Casper wrote:
Vadim Gritsenko wrote:
In all other situations, Carsten is right - this might cause backward incompatibility. This is important for user-facing classes. Should we start marking classes as internal, like "<b>INTERNAL!!!</b>" in javadoc or some such?
What about introducing @cocoon.usage tags I proposed a while ago like: @cocoon.usage published
or: @cocoon.usage flowscript
etc.
This might someday also be used to generate separate Javadocs for different APIs.
Hm, noone (but me :-) seems to like the idea.
So maybe it's a good idea to first have a quick vote about whether to mark internal classes as such or to mark "published classes/interfaces" as such (and then decide how to mark them).
+1
Sorry, I think I was not clear (my fault). I intended the vote to be about marking (like within javadocs) either:
-internal classes
or (the opposite):
-published classes
The first is what Vadim suggested and most simple to do (there are just a few internal classes).
The latter opens the door to further classify classes/interfaces.
OK, I get it now. Let's start with marking internal classes then. This is what is needed most ATM in order to allow the cocoon internals to more freely evolve.
-- Unico
