cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: [cocoon-2.2] Deprecation
Date Thu, 08 Nov 2007 14:58:43 GMT
Joerg Heinicke pisze:
> 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?

Waiting a little bit and let the requirements to crystallize is a good idea in general. The
process
of crystallization of ideas will shape replacements for the functionality we want to deprecate.
At
the same time we can (and should in my opinion) deprecate things without having "1-1" replacements
or even ideas for them.

Why can't we wait? Because cocoon: + map:mount combo is a major pain whenever one wants to
touch
Cocoon's core. I'm almost sure that there is no active committer that could say: I know how
this
stuff works or at least I could figure out everything I need to work with this code in a day.
Don't
you think that having big portion of such code in core will bite us in the future only if
it's not
biting us now?

Deprecation of this stuff would hold mainly informative role spreading a clear message: We
really
want to remove this code and we are actively evaluating various options as replacements. I
would
even say that deprecation would elicit active discussion amongst our users. That would be
the best
outcome of the whole deprecation thing at this point because we probably could gather a lot
of
useful information how Cocoon is used.

Yes, as several folks pointed out, deprecation is only the first step to remove any portion
of code.

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

Can you explain what do you mean by "fall-through of sub sitemaps"?

>> 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?

There would be no impact on our users apart from the psychological aspect I spoke about earlier.

Do we agree on deprecating this stuff then?

-- 
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/

Mime
View raw message