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. Carsten
