Ralph Goers pisze: > > 2.1 is Java 1.3. No release of 2.1 should be anything else.
I don't want to change Java compatibility in 2.1, even more I don't want to change anything in 2.1 any more. I didn't make it clear: I want to kill 2.1.x because I believe we should maintain at most two branches. Killing 2.1.x should enable us to maintain 2.2.x and focus on trunk introducing Java 1.5 as minimal requirement and some other incompatibilities. > What happened to item 2? Good question. I was having bad night. If I recall what it was I'll post it :) >> 3. Let's release 2.2 final just few weeks after RC2 (probably at the >> beginning of November) and >> start 2.2 branch just for the core modules > > 2.2 has never been formally released. The way I understand it the way our > versioning rules work we can make this dependent on any Java version we > want. Yep, but changing contracts when second RC is just about being pushed is not the best solution IMO. >> 4. Let's start working on 2.3 in trunk with clearly set of general >> features we would like to see in >> clearly set time-frame with preference of time-frame over feature-set. I >> mean, if something does not >> make it into 2.3 in planned time-frame it must be rescheduled for 2.4. At >> the same time, we could >> set Java 1.5 for trunk. > > Version 2.3 should only be created if we have some new feature for it .. > like OSGi (and it might even be possible to do that on 2.2 since it is > leveraging Spring - but you'd have to ask the guys working on it). I am > not in favor of creating a new release branch just to increase the minimum > Java version. If that is done I doubt 2.2 will get any new features or > support so what is the point. What about some less distant and less ambitious goals like further splitting of cocoon core, less number of dependencies on Avalon and new EL stuff as default for sitemap? I would like to include in this list other goals like finished implementation of postable source and its infrastructure (like caching) but this is not going to be in 2.3 or even 2.4 of Cocoon core. It's going to be feature of 1.1 version of servlet service fw. I mean that we should be less ambitious about cocoon core when it comes to feature-set for particular release because most of the interesting stuff will be *outside* core. When it comes to OSGi integration I keep my fingers crossed for this effort and I even would like to join into this camp eventually but I think OSGi should not block any release. It must be desire and labour of community to act as lifeblood not just our wishes. >> I think it's the right time to refer to Marc's Portier e-mail[1], >> especially that we are just before GT: >> >> I agree, let's move on. >> > > Hmm. I hope you don't mean that in terms of moving on to Wicket or Ruby on > Rails or whatever the newest web framework is. ;-) In no case! :-) -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
