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 <[EMAIL PROTECTED]> wrote:
On 6/22/07, Gary VanMatre <[EMAIL PROTECTED]> wrote:
> >From: "Greg Reddin" <[EMAIL PROTECTED]>
> >
> > 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.
>
<snip/>
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.
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 :-). 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
