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
