cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: Release Cocoon 2.2RC2
Date Mon, 27 Aug 2007 13:27:03 GMT
Reinhard Poetz pisze:
> 
> I plan to release Cocoon 2.2RC2 between Sept 19th and Sept 21st,
> provided that I have enough time to publish our new documentation
> before  because it doesn't help much if we release things without
> telling anybody about it ;-)

+10000!

In response to some Carsten e-mail I said that I was planning to take care of releasing in
late
September. You were faster with concrete proposal I'm fine that you take care of it and I
would like
to lend my hand if any help is needed.

> Does anybody have problems with a code freeze from 18th to 21st of
> September in trunk?
> 
> I plan to release following artifacts:
> 
> org.apache.cocoon:cocoon-core:2.2.0-RC2 (+ all submodules)
> org.apache.cocoon:cocoon-configuration-api:1.0.1 *
> org.apache.cocoon:cocoon-spring-configurator:1.0.1 *
> org.apache.cocoon:cocoon-servlet-service-components:1.0.0-M3
> org.apache.cocoon:cocoon-servlet-service-impl:1.0.0-M3
> org.apache.cocoon:cocoon-flowscript-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-template-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-apples-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-linkrewriter-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-auth-api:1.0.0-RC2
> org.apache.cocoon:cocoon-auth-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-batik-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-captcha-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-databases-mocks:1.0.0-RC2
> org.apache.cocoon:cocoon-databases-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-databases-hsqldb-client:1.0.0-RC2
> org.apache.cocoon:cocoon-databases-hsqldb-server:1.0.0-RC2
> org.apache.cocoon:cocoon-fop-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-html-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-mail-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-22-archetype-block:1.0.0-RC2
> org.apache.cocoon:cocoon-22-archetype-block-plain:1.0.0-RC2
> org.apache.cocoon:cocoon-22-archetype-webapp:1.0.0-RC2
> org.apache.cocoon.cocoon:5
> org.apache.cocoon:cocoon-core-modules:5
> org.apache.cocoon:cocoon-blocks-modules:5
> org.apache.cocoon:cocoon-tools-modules:5
> org.apache.cocoon:cocoon-maven-plugin:1.0.0-M2**
> org.apache.cocoon:cocoon-rcl-spring-reloader:1.0.0-M2**
> org.apache.cocoon:cocoon-rcl-webapp-wrapper:1.0.0-M2**
> 
> * if Carsten wasn't faster ;-)
> ** if necessary because of changes in core that make M1 unuseable
> together with cocoon-core-2.2.0-RC2.
> 
>                                      - o -
> 
> A note to Grek:
> 
> As part of the expression module documentation you write that you want
> to release 1.0.0-M1 of the expression modules. For the time being I'm
> against having seperate releases of cocoon-core sub modules but always
> release them as a whole, at least for now*. We adivce our users that
> they should only have dependencies on cocoon-core and not on one of its
> submodules.
> 
> Or do you see a particular value in a release of the expression modules
> that would  make it worth to make an exception from this rule?

EL stuff is completely independent from rest of core, it has no dependencies on cocoon modules
so
there is no problem with releasing it independently.

On the other hand, if you are going to release rest of Cocoon there is no point in releasing
it few
days earlier. ;)

My long-term goal is to stabilize development of EL to such extent that we can switch to the
released dependencies even in Cocoon's core.

> * I will change my opinion if cocoon-core doesn't contain Java code
> anymore and everything is at its right place ...

I've taking a look on this issue when working on GSoC and moving stuff around. Basically we
have:

  * code that can be moved immediately because there is no problem with dependencies

  * code that has some very complicated dependencies like CocoonSourceResolver

  * code that itself does not have any problems with dependencies but its tests depend on
code from
cocoon-core like CocoonTestCase. We can get rid of CocoonTestCase reliably only switching
from
Avalon to Spring so our components become beans thus much more test-friendly.

We could think about spending some time on it at Hackathon, WDYT?

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

Mime
View raw message