I definitely think you misunderstood my point. As Vadim rightly pointed out, I should have ONLY been talking about 2.2 (i.e. trunk). See below for more.
Grzegorz Kossakowski said: > Vadim Gritsenko pisze: >> Ralph Goers wrote: >>> Unless the -1 is rescinded I fear *2.2* will be stuck at 1.4 until >>> 2010. >> >> Here, fixed it for you :) >> >> You are saying it like a bad thing. Cocoon 2.1 will be stuck at Java 1.3 >> until cows come home. And Cocoon 1.8.2 will be stuck at... Well, you get >> an idea. I'm completely expecting Cocoon 2.3 to be at Java 1.5 level, >> and 2.4 may be at Java 1.6 level. >> >> Our problem is not minimum Java requirement for Cocoon 2.2. The problem >> is release time lines. Cocoon 2.2 was supposed to be "Cocoon 2.1 + >> ECM+". Now we don't have ECM+, it went through Spring migration, there >> seems to be second wave of OSGi activity - and 2.2 ain't released yet. >> Now *that* would be a good reason to flame. Java requirements? Nah, >> that's peanuts... > > Vadim, you have a really good point, here. > > Not to respond to all e-mails I will summarize my standpoint: > I agree that Java 1.4 compatibility becomes more and more illusory as > people are abandoning Java > 1.4. I agree that we should drop support for Java 1.4 ASAP but I strongly > insist on respecting > versioning rules and keep our word at the same time. Here we come to > Vadim's point that we release > much too rarely. > That's why I would like to: > 1. Release 2.1.11 ASAP (I would take care of it after GT) and we should > agree on the fact that > 2.1.12 will be released soon (after two months from 2.1.11 release) and it > kills 2.1.X branch > *definitively* (except serious security flaws, of course). 2.1 is Java 1.3. No release of 2.1 should be anything else. What happened to item 2? > 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. > 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. > > I think it's the right time to refer to Marc's Portier e-mail[1], > especially that we are just before GT: > >> If I'm missing anything in our 2.2. moves then it is a "clean slate" and >> some freshly burnt down bush and rainforest to start growing new ideas. >> It feels (from some distance, I admit) as if we keep dragging our >> history with us, rather then only our witty experience. >> >> >> As Stefano clearly stated almost 2 years ago: "It is time to move on". >> The biggest difference now is that there might be a bigger base of >> people ready to do so, and with a more clear view on 'where to'. > > 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. ;-) Ralph
