Brett Porter wrote:
On 24/04/2009, at 12:01 PM, Brian Fox wrote:
On 4/23/2009 9:57 PM, Brett Porter wrote:
On 24/04/2009, at 9:55 AM, Brian Fox wrote:
I agree, if we call it 2.2 because it moves to jdk 1.5 and we fix
the other stuff, great. But lets keep the scope very small and
limited so we can get the regressions in 2.1.0 out quickly.
I don't think there's any harm in that. Version numbers are cheap. I
agree, it's important we define scope and stick to it, whether it is
short or long.
But as I said before, while flipping to JDK 5 feels a bit icky, I'm
kind of alright with it for 2.1.1 if we limit it in scope to just
this change. Preferably not, but I don't think it's going to kill
anyone.
Perhaps there is an alternative. John, what about if we retain 2.1.0
behaviour on JDK 5 for this? ie, catch an exception on a class not
found and drop back with a warning in the console to use JDK 5 if you
are affected by that issue. Keep source/target as 1.4.
If you have source 1.4 then you can't use the 1.5 apis can you?
Pretty sure you can (type erasure and all that, and I doubt XPath is 1.5
specific).
I'm happy to give this a run and see what happens. I'd prefer not to get
into the inevitable expansion of scope - or at least a lot of discussion
about why we're not expanding scope - that would come with a 2.2 version
change. I do see the point in not surprising users, too, so this might
be a decent way out, if it works. Another approach that's almost as ugly
as the line-reader approach might be traversing the DOM with some custom
code, though I haven't gotten my head around that as a solution yet.
What documentation standards do we need to adhere to for this sort of a
warning? I'm assuming it'd be good to give them a URL for more
information...is the JIRA enough, or do we need website docs for the bug?
-j
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
