Not so. The branch was created off of the 1.1.0 release point. Bill, please correct me if I am wrong.
sean On 10/24/05, Simon Kitching <[EMAIL PROTECTED]> wrote: > Sean Schofield wrote: > > 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. > > Well, yes the commit *was* done on TRUNK. But the 1_1_1 branch was > created in R291992, so the change is *also* present in the 1_1_1 branch. > > Regards, > > Simon > > > > > 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 > >>>> > >> > > > >
