myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@obsidium.com>
Subject Re: RC3 Status
Date Mon, 24 Oct 2005 22:40:51 GMT
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 <skitching@obsidium.com> 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 <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