Daniel Fagerstrom wrote:Reinhard Poetz wrote:Daniel Fagerstrom wrote:<snip/>I think your ideas lead into the right direction! Though I think we should agree on a feature freeze *now* and release ASAP.Although I also would like a stable 2.2 right now ;), I don't think that is the way things work. Now one seem to have the itch to finish cForms or VPCs at the moment while Carsten (and others) seem to spend considerable energy in improving the core and the configurations.
Having a modularized configuration was really a requirement, as it was - far more than an unstable cforms - making the configuration of Cocoon a real pain and I had the (unfortunate) opportunity to meet people that were considering Cocoon for their projects but ran away when seeing how complicated it is to configure it.
That's why I added include in xconf, and it seems this answered a need considering how people are now building around this.
Sorry for not refering to your work, Carsten has flooded the SVN log mail list lately so I got it wrong ;)
Anyway my main point was that I find modularized configuration much more important than stable CForms and VPCs.
Furthermore, IMO it would really be worthwhile if we could get to the point where the blocks are removed from trunk and contains there own configuration, gump descriptor and ant script as discussed earlier in this thread.
Consequences of this would be that we could release core Cocoon independently of the blocks, the percived complexity of Cocoon would decrease considerably. The contract for projects like Forrest and Lenya that depends on us would be much easier to maintain, they could start to package their stuff as blocks. It would lower the barrier to start contributing to Cocoon when blocks developed at SourceForge would be nearly as easy to use as blocks developed by committers.
Now about CForms and VPC, I plan to spend some time on it in one week, while on vacation (that's when I have time for sustained development effort on Cocoon lately), starting with CForms which seems more important to me than VPCs, as - from a release POV - stabilizing an existing feature is better than working on a new one.
Excelent!
IMO we could start releasing 2.2 when Carsten have achived his current goals with the kernel (whatever they might be ;) ) or runs out of steam.
I don't think feature freezing is the right thing to do when we have a lot of inertia.
Having said that I would like to do something about the VPCs, but I haven't researched the current implementation enough to know if it is straight forward or if it requires considerable refactoring of the sitemap engine and the environment handling.
I does require a substantial amount of refactoring of the sitemap engine and environment handling...
I was afraid that it was that way :/
BTW: did you see http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110539791029866&w=2 ?
/Daniel
