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/
