Andreas Hartmann wrote:
> Jann Forrer schrieb:
> 
> [...]
> 
>> If we choose 2.x we should avoid to break backward compatibility
>> (and now the mantra: Do not break it in 3.0 either without presenting a
>> migration path ;-) )
> 
> I understand that backwards compatibility is a very sensitive subject.
>

Especially for an "admin" point of of view, if every upgrade needs
a lot of extra work. However, already the description of a migration path
could help. We recently upgrade a request tracker installation from 3.2
to 3.6 (or so). Backwards compatibility was broken but they provide a
migration path including some scripts.


> For the content repository, we have to provide an automatic migration in
> any case. But this shouldn't be too hard now since we have a
> self-contained, non-configurable repository (the SourceTypeAction and
> DocumentIdToPathMapper can't do any harm anymore).
>
:-)

> With our sitemap "API", we can barely change anything without breaking
> backwards compatibility. We haven't introduced a way to declare
> pipelines as private, so virtually all core and module pipelines can be
> called by custom code. The same applies to XSLTs, JX templates and the
> like.
> 
yes is understand that but at least for publications, which are based on
the default publication, upgrade should be as easy as possible.
And with the module concept in 2.0 custom code is better isolated from
"lenya code".

> With the Java API, the situation is a bit better since we have separated
> the actual API from the implementation. We can try to preserve the API.
> But the more important is it that we discuss all API additions
> thoroughly (see for instance my thoughts about the search API, I'm
> reluctant to provide code before knowing more opinions).
> 
That's true.

Jann


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to