AFAIK the 1.1.1 branch is based on trunk rather that 1.1.0. I agree to Sean that we should get out the 1.1.1 release as soon as possible.
myfaces derives its version numbers from the spec. JSF 1.1 (JSR 127) is currently implemented which is the reason why we start myfaces version with 1.1. This is also the reason why the release after 1.1.1 is called 1.1.2 and will definitely not backward compatible if someone relies on specific myfaces implementations. It will only backward compatible for the spec api and definitions. So 1.1.0 -> 1.1.1 is not supposed to be a patch only for tomahawk components but for spec relevant issues. 2005/10/25, Simon Kitching <[EMAIL PROTECTED]>: > > svn log --stop-on-copy --verbose . > > ------------------------------------------------------------------------ > r291992 | bdudney | 2005-09-28 05:33:25 +1200 (Wed, 28 Sep 2005) | 1 line > Changed paths: > A /myfaces/tomahawk/branches/1_1_1 (from /myfaces/tomahawk/trunk:291991) > > Tagging the 1.1.1 release. > ------------------------------------------------------------------------ > > Note: "(from /myfaces/tomahawk/trunk:291991)". > > Regards, > > Simon > > Sean Schofield wrote: > > 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 > >>>>>> > >> > > > > -- Mathias
