Sylvain Wallez wrote:

Reinhard Poetz wrote:

AFAIU only some work on cForms is missing (flowscript API and repeater binding)



That's far from the only work to do IMO, as there are a lot of semi-finished core features. Some that come to mind: refactored object model,

Here the main problem is that JXTG and flow have some differences in behaviour, see http://marc2.theaimsgroup.com/?t=111648265000001&r=1&w=2 and http://marc2.theaimsgroup.com/?l=xml-cocoon-dev&m=111666682531907&w=2 for description and possible solutions. We need to decide: should we keep trhe direct access of request params as properties of cocoon.request and session/context attributes as properties of cocoon.[session|context] or not. Should we support the direct usage of org.*, javax.* and com.* whithout needing the Packages. prefix in flow?

Is there anythimg more?

sitemap listeners,

VPCs,

I'm waiting for community involvement.

If we follow Vadim's suggestion http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111331073205551&w=2, nothing in core need to depend on vpc code and the vpc code could be mocīved to an own (unstable) block.

third-party containers, etc. Not that these features don't work, but they lack (at least that's my impression) some more use cases and demos to be strong enough for a stable release.

Sure, we can make an alpha release to give people a sign that we are doing some progress, but this should be for us the sign that no more features should be added in that branch.

As discussed in the relases thread I don't think it is realistic to stop adding features, we need a way to let rock stable core functionality coexist with new features. Otherwise the defacto "no release" policy will continue.

/Daniel

Reply via email to