Check your SVN again. r291865 was on the trunk not the branch. So now you have proved my point. It was not introduced on the branch so a fix in 1.1.1 is unecessary.
sean On 10/24/05, Simon Kitching <[EMAIL PROTECTED]> wrote: > See comments inline... > > Sean Schofield wrote: > > 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. > > I understand all about lack of time :-). > > The 1.1.0 release was R280683. > > The problem was introduced in R291865, which is definitely in the 1_1_1 > branch: > http://svn.apache.org/viewcvs.cgi/myfaces/tomahawk/branches/1_1_1/src/java/org/apache/myfaces/custom/navmenu/jscookmenu/HtmlJSCookMenuRenderer.java?rev=291992&view=log > > An alternative to applying my patch would be to roll back to the version > prior to R291865, and then reapply the two patches that were added on > the branch since that patch. > > > > > 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. > > > There will be lots of people who *haven't* tested the RC releases. They > are likely to get an unpleasant shock when trying to upgrade from 1.1.0 > to 1.1.1. They *will* be stuck with 1.1.0, ie will not be able to get > the patches in this release without changing their code. That's > something people expect in a 1.x -> 2.x change, and will grumble about > but probably accept in a 1.x -> 1.y change. But 1.1.0 -> 1.1.1? > > Anyway, applying the fix is about 5 minutes work for someone who already > has RC3 checked out and building. It's probably about 30-45 mins for me > who doesn't have that done. And the TCK isn't an issue as this is a fix > in the TOMAHAWK bits only. > > > Regards, > > Simon > > > > > > > > > > sean > > > > On 10/24/05, Simon Kitching <[EMAIL PROTECTED]> 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 > >> > > > >
