On 07.11.2007 15:52 Uhr, Grzegorz Kossakowski wrote:
Now, at some point we have to break compatibility to get a cleaner
architecture and an even better way of doing things. Perhaps removing
sub sitemaps is one of these things, perhaps not.
Before we start to think about migration path and embedding 2.1 as "emergency
help" for existing
users I really think we should agree what we are going to deprecate and remove
in the future and
most importantly how we envision future Cocoon's architecture so there will be no
"perhaps yes,
perhaps no" doubts any more.
It seems we do not even know the requirements. How do you want to decide
about architecture without them? My guess - since Cocoon is just a
framework - you merely get the requirements from real applications built
on it. Why can't we wait until the people get used to the new
functionality and see how it works out to see what can be removed in the
future?
From what I understand servlet protocol lacks some major functionality
like the fall-through of sub sitemaps. This seems to be the most
important convention over configuration feature.
If people don't want to migrate I would tell them to stick to 2.1, it's stable
and final release of
2.2 won't make 2.1 unusable.
I want them as testers sharing their experience. Otherwise it takes much
longer to get peoples to use Cocoon 2.2 in a meaningful way (= more than
starting with little applications). I don't see the point preventing
people from migrating. Also we are talking about *deprecation* in 2.2
here, not removing features. So how should it affect them?
Joerg
