cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [RT] The future of our lifecycle extensions in 2.2
Date Thu, 08 Jan 2004 15:06:31 GMT
Sylvain Wallez wrote:
>
> Carsten Ziegeler wrote:
>
> <snip/>
>
> >So, I'm in favour of deprecating this in 2.1 now and removing it in 2.2.
> >
> >
>
> While I'm more than ok with simplifying stuff, we have to take great
> care of backwards incompatible changes.
>
Absolutely.

> Our version-naming scheme "x.y.z" states that compatibility should be
> ensured between different "y" versions. This has not been exactly the
> case between 2.0 and 2.1, and I fear that the more radical changes that
> occur between 2.1 and 2.2 will lead to more incompatibilities.
>
I hope, that we only have minor incompatibilities.

E.g. regarding the lifecycle extensions, I guess that only few people are
using them and we over an option. So with minor code changes everything
is still possible.

I think, refactoring and changing things is unavoidable even between
different
"y" versions. Otherwise you end up with very ugly designs and problems
over problems.
Of course, we should document every incompatibility and provide an
alternative.

> So the question is: aren't we moving towards a 3.0 release?
>
I think this is not required.

> Or shouldn't we make more effort at defining Cocoon's public and private
> APIs? I made a proposal a while a go for this, based on javadoc
> attributes, but never investigated it further.
>
+1

For 2.2 I moved most of the private stuff into a separate package, so we
can simply say don't use anything from this package.

> Should we make this a high priority task, so that we can distinguish
> what we consider to be Cocoon's internal from the officially
> supported API?
>
Sounds good.

Carsten


Mime
View raw message