myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Schofield <sean.schofi...@gmail.com>
Subject Re: RC3 Status
Date Mon, 24 Oct 2005 21:52:01 GMT
I haven't investigated this issue very closely but I doubt that
changes in the 1.1.1 branch caused this bug.  Its certainly possible
but we've been limiting the changes to must have fixes.  Its hard to
imagine one of these changes impacting jsCookmenu.

Unfortunately I do not have time to track this down and prove it to
you.  If the other committers have the time and inclination to track
this down, fix it, build a new RC, rerun the Cactus tests and then
rerun the TCK then perhaps they will agree to your request.

My guess is that everyone wants to move on with this release since we
don't have concrete evidence suggesting that *new* bugs have been
introduced on the branch.  Its not like you (or anyone else) is stuck.
 The bug has been fixed on the trunk so what's the problem?  I'd
rather get to work on a 1.1.2 release with a ton of other changes that
have happened on the trunk.

sean

On 10/24/05, Simon Kitching <skitching@obsidium.com> wrote:
> Sean Schofield wrote:
> > IMO that is NOT a blocker for the 1.1.1 release.  There are lots of
> > little issues with Tomahawk components.  If we waited to get every
> > last one done we would never release.  The main thing is to get this
> > out so we can fix the problem with myfaces-all.jar in 1.1.0 (a
> > legitimate blocker.)
>
> This is a change in a "patch release" (1.1.0 -> 1.1.1) which breaks
> backwards compatibility.
>
> Any jakarta commons project would consider this a blocker issue. I (as a
> commons committer) would certainly veto any commons library release with
> such a change in it. Any commons component can be upgraded from 1.1.x to
> 1.1.y with confidence that no valid code will stop working, and I
> believe that is a reasonable expectation.
>
> The change to jscookMenu, however, will break every application out
> there that uses a custom theme; there was only one way to implement a
> custom theme up until now (AFAIK) and changes made since 1.1.0 now cause
> that approach to throw an exception. The patch that was applied to TRUNK
> ensures that code that used to work will still work.
>
> Note that this is not an issue I personally care about; I'm currently on
> 1.1.0 and am likely to move direct to TRUNK soon as there is some good
> stuff there which has (correctly) not been put into the 1.1.1 "bugfix"
> branch.
>
> Regards,
>
> Simon
>

Mime
View raw message