I'll help with testing java 6 and java 7 from Oracle. I vote for keeping up with latest and greatest, but we should also respect that many distros are probably going to ship java 6 for a while.
Thus, we should probably work with both then officially deprecated java6 when it's time. Fred On Mon, Feb 11, 2013 at 11:06 AM, Michael Lam <mnsyl4...@verizon.net> wrote: > On 02/11/2013 01:16 PM, Kay Schenk wrote: >> >> On Mon, Feb 11, 2013 at 9:24 AM, Herbert Duerr <h...@apache.org> wrote: >> >>> Hi Michael, >>> >>> >>> On 11.02.2013 17:21, Michael Lam wrote: >>> >>>> I have successfully test hsqldb-2.2.9 against the following 4 issues and >>>> it is functioning correctly: >>>> >>>> https://issues.apache.org/ooo/**show_bug.cgi?id=96823<https://issues.apache.org/ooo/show_bug.cgi?id=96823> >>>> >>>> https://issues.apache.org/ooo/**show_bug.cgi?id=103528<https://issues.apache.org/ooo/show_bug.cgi?id=103528> >>>> >>>> https://issues.apache.org/ooo/**show_bug.cgi?id=104901<https://issues.apache.org/ooo/show_bug.cgi?id=104901> >>>> >>>> https://issues.apache.org/ooo/**show_bug.cgi?id=97032<https://issues.apache.org/ooo/show_bug.cgi?id=97032> >>>> >>> Thanks a lot for investigating this! >> >> >> yes, great news! >> >> >>> >>> and I have looked at >>>> >>>> >>>> http://hg.services.openoffice.**org/cws/hsqldb19/<http://hg.services.openoffice.org/cws/hsqldb19/> >>>> >>>> Unless I am looking at this wrong, many of the changes are not related >>>> to hsqldb19 and it is already in the latest revision. As for the hsqldb >>>> specific, the patches does not apply to 2.2.9. As far as patches, >>>> wouldn't it be better to report upstream and provide the patch instead >>>> of just patching within the build? >>>> >>> Definitely. >>> >>> In a linux distribution or a project such as ours with so many external >>> dependencies there are good reasons not to always use the latest version >>> of >>> each component: That could easily result in endless churn and prevent >>> releases. So backporting fixes is an alternative that should is often >>> preferable. I don't know the background of the issues mentioned above >>> that >>> were fixed for HSQLDB but maybe they were such backports of fixes? >> >> >> I thought the main reason for investigating the HSQLDB upgrade/change was >> due to issues between java 6 and 7? we have some other patches submitted >> to >> help with that also. I could be wrong about this though. >> >> >> >>> >>> There are also checks within the code >>>> >>>> to specifically check for version 1.8.x, not sure wouldn't it be better >>>> to enforce on configure/bootstrap? The current way seem to require a lot >>>> more work to update dependencies and the with-system-hsqldb for >>>> configure provides no warning. >>>> >>> Using configure for checking this and cleaning up checks for obsoleted >>> versions is a good plan. Please go ahead. >>> >>> >>> I will take a look at the open issues and see if it is resolved with >>> the >>>> >>>> new version. >>>> >>>> I am guessing my next steps would be looking into updating the build to >>>> pull the jar? >>>> >>> Better use the mechanism provided by main/external_deps.lst >>> >>> Herbert >>> >> >> > It is partially to address the JDK issue but there have been improvements in > HSQLDB for both performance and conformance that would be helpful which is > why I lean more towards updating to the latest rather than patching the > existing. I understand it would be difficult to constantly update to the > latest release of a dependent project both in a quality and release > standpoint. With adequate planning and testing, the code should also allow > for an update to the latest without too many gotchas.
