>From: "Craig McClanahan" <[EMAIL PROTECTED]> > > Sorry for the late response ... still catching up from a backlog due > to being on the road for most of May. Comments below. > > On 6/22/07, Rahul Akolkar wrote: > > On 6/22/07, Gary VanMatre wrote: > > > >From: "Greg Reddin" > > > > > > > > On 6/22/07, Rahul Akolkar wrote: > > > > > > > > > > On 6/22/07, Matthias Wessendorf wrote: > > > > > > hi, > > > > > > > > > > > > are there any plans for 1.1.0 release ? > > > > > > > > > > > > > > > > As an aside, IMO its worthwhile to have a v1.0.5 as well so we can > > > > > attempt to go GA in the 1.0.x line. Opinions? > > > > > > > > > > For the most part, the trunk and 1_0_x branch are the same. I can only > think of one commit that was not made to the both. I'd like to see us move > the > trunk to JSF 1.2 and then we could mix in the annotations as part of the base > libraries. > > > > > > > > > shale-dialog has considerable deltas (the helper class, some new > > listener methods etc. -- many @since 1.1.0 tags if you dig into the > > code). This was under the understanding that no new features went into > > the 1.0.x line after v1.0.4. > > > > If we want to move trunk to JSF 1.2, that should either happen at > > v1.1.0 or should wait for the next line of development (v1.2.0) IMO. > > Depending on JSF versions and when currently unreleased new features > > frum trunk get released, here are the potential release scenarios: > > > > SCENARIO A: > > > > 1.0.x --> JSF 1.1, no new features beyond v1.0.4 > > 1.1.x --> JSF 1.1, seeded from current trunk > > 1.2.x --> JSF 1.2 > > > > SCENARIO B: > > > > 1.0.x --> JSF 1.1, no new features beyond v1.0.4 > > 1.1.x --> JSF 1.2, seeded from current trunk > > > > SCENARIO C: > > > > 1.0.x --> JSF 1.1, merge current deltas (mostly dialog new features) from > > trunk in 1.0.x line > > 1.1.x --> JSF 1.2, seeded from current trunk > > > > Preferences? > > > > My personal preference would be for scenario A over scenario B or C, > but with a twist ... target the JSF 1.2 based stuff for a 2.x release > series, rather than 1.1 or 1.2. Why? Because a redesign of the > existing APIs to take JSF 1.2 into account (and therefore also become > dependent on Java SE 5) is very likely to require some significant > changes (just as one example, much of "tiger" basically goes away and > becomes part of the core functionality in "view" and other places), so > upping the major version number would be more appropriate. >
I'd like also like to see the annotation processor moved to the core with a pluggable way to register handlers. It seems silly to scan the classpath multiple times for each library that might have future annotations. Maybe a commons chain would be a good way to register annotation handlers? > Version numbers aside, I would prefer A over B. We need to put out a > new release anyway; the ease of use additions in the current trunk are > modest but nice, and if we focused on just finishing 1.1 we might > actually get a release out this year :-). +1 > I don't like C -- we still > want to have the *ability* to go back and do a 1.0.5 if some security > problem or something rears its head; in the mean time, lets just get > 1.1 done and out the door while we start talking about what the future > might hold. And that starts from us (yes, me included :-) rolling up > our sleeves and addressing the current issues in the trunk code -- and > *perhaps* backporting bugfixes to the 1.0 branch, but that needn't be > a priority. > > > -Rahul > > > > Craig Gary
