myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Travis <jtra...@p00p.org>
Subject Re: RC3 Status
Date Wed, 26 Oct 2005 00:44:35 GMT
Seems like a very bad idea to bind Tomahawk components to
the same version number.

Having a version number that tells your client something
about what to expect when upgrading is a _good_ thing.
People can usually upgrade bugfix revisions without
worring about re-writing code (i.e. non-backwards compatable
changes).

The way you have it versioned now, tomahawk components will
only ever increase in bugfix version # for a specific JSF
spec (1.1, etc.)  That doesn't seem like what you want.  You
definitely want to be able to make incompatable changes
in tomahawk components in the future.

-- Jon


On Oct 25, 2005, at 1:42 AM, Mathias Brökelmann wrote:

> 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 <skitching@obsidium.com>:
>
>>
>> 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 <skitching@obsidium.com> 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 <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
>>>>>>>>
>>>>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
> --
> Mathias
>
>
>



Mime
View raw message