cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: [Plan] The future of Cocoon
Date Thu, 27 May 2004 14:11:10 GMT
Sylvain Wallez wrote:
> -1: XSP has been moved to its own block meaning it's no more 
> "core", but hundreds (if not thousands) or people are using 
> it on a daily basis. We can drive people towards new 
> techniques such as flow/jxtemplate, but cannot deprecate 
> what's has been a central part of Cocoon for so many years.
> Personal note: your post made many people rush into my office 
> saying "What, what, deprecate XSP? He's crazy!" ;-)
Now they are calling me "crazy" - well... :)

Deprecating doesn't mean removing! by deprecating we show our users
that we think that there are better ways than XSP. And we show that
we are not developing this technique further (of course bug fixes
etc will be applied) That's all. We *can* than remove XSP in another
minor or major release, but we don't need to. So, this is just
a signal.

> >- cleaning up the caching/store mess
> >  
> >
> What's left to do here?
I will write an RT soon (next week I guess).

> >- remove deprecated blocks etc.
> >  
> >
> Mmh... this breaks compatibility. 
No, it doesn't :) (Well, yes, it does, but) According to our versioning
guide we can remove deprecated things with a new minor version and we
can start following this - we don't have to. I think there is currently
only one deprecated block anyway.

> Taking Ugo's idea, what 
> about creating an additional categorization level for blocks, 
> such as "experimental", "samples", "applications", 
> "deprecated", "archive"?
Í have nothing against it - but at some point of time you have to get
rid off deprecated things; otherwise you kill your architecture sooner
or later. So deprecating things soon, give an alternative and then
remove the deprecated things after a time is imho the right way to
go. Otherwise deprecating doesn't make that much sense.


View raw message