cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: Proposal: release management guide (was Re: [RT] Versions)
Date Wed, 21 Apr 2004 17:52:49 GMT
On 21.04.2004 09:33, Carsten Ziegeler wrote:

> Usage Compatibility
> -------------------
> 'Usage' compatibility guarantees that an application written 
> by a Cocoon user is compatible. All files developed by a typical 
> Cocoon user like xml files, sitemaps, stylesheets (elements and 
> namespace declarations) keep on being picked up by the machinery 
> and are dealt with correctly (sitemap semantics, 
> generator/transformer-picked up elements, config file entries...). 
> In fact this should cover everything (including flow script) but 
> except own Java code.
> Applications that write against a particular version will remain
> usage compatible against later versions, until the major number 
> changes.
> Writing an application against a version means that this application
> does not use any deprecated API of that version. Therefore minor 
> version changes are only usage compatible from one minor version to 
> the direct following one. For example 2.2 is usage compatible to 2.1.
> But 2.3 is not necessary usage compatible to 2.1, although it is 
> usage compatible to 2.2. As long as you don't use deprecated API,
> your application is usage compatible across all minor versions.

Somewhat inaccurate. IMO it must read "As long as you don't use 
deprecated API and the API you rely on does not get deprecated, your 
application is usage compatible across all minor versions."

> Example: 
> - a feature is introduced in 2.0 and used by the application.
> - it is deprecated in 2.2.
> - it will be removed in 2.3.

Otherwise this would oppose to this example.

> External Libraries
> ------------------
> Cocoon uses a set of external libraries (like for example Avalon, 
> Xalan or Xerces). Inbetween any release, even patch releases,
> the versions of the external libraries might be updated to any version.
> Therefore if your application is written against a special API of an 
> external library it might be that this API of the external library 
> changes inbetween two Cocoon versions and therefore your application 
> does not work properly anymore (or even does not compile anymore).
> Unfortunately, this issue is out of the scope of Cocoon.

Let's restrict this to updates of libraries without the need for 
touching Cocoon code. This means the user must be able to revert the 
update for his local cocoon installation.

> This high innovention has - at least in theory - the price of maintaining

innovation + invention = innovention ;-)


View raw message