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 <[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
