Re: 10.2 plans (was Re: 10.2 licensing issue)
David Van Couvering wrote: A quick chime in. I am not comfortable with a source-only release of 10.2. I think a binary release without JDBC4, plus the source for the JDBC4 functionality for those who want it and are prepared to do a build (e.g. option 2) seems quite reasonable to me. Neither am I. I was thinking combined. 10.2 w/o JDBC4 compiled with JDK 1.5, 10.2 source compilable with JDK 6 for this interested in JDBC4. David Bernt M. Johnsen wrote: Rick Hillegas wrote: Hi Dan, Daniel John Debrunner wrote: Since this is an open-*source* project, we do have other options that seem to have no legal issues to me (IANAL). Option A - Source only release with JDBC 4.0 based on proposed final draft Derby 10.2 release is source only, no pre-compiled jars, removes the dependency on the Mustang download. This would seem to require that users become developers, at least to the point of creating a development environment. Well. Derby is *not* an end-user product, so the Derby users are themselves developers. I had an unhappy initial experience as a Derby developer a year ago. Perhaps the situation has gotten better. I recall that setting up a development environment involved a lot of steps and moving parts--fetching various pieces of software from various locations, editting ant configuration files, etc.. I think that may discourage many users. That in turn will limit the commodity testing and feedback which we hope to get from users of the official release. I see your concerns. But I have done this maneouver several times in my career with various open source products (the list is very long, but I started with some platform problems with emacs on Sun386i in the late 80s), and the build process wasn't always smooth (I even once had to edit a files in SunOS /usr/include to make gcc compile). Don't underestimate the Derby users. In addition, an uncontrolled build process would very likely complicate bug reporting. For these reasons, I would recommend against this option. The option will always be there for the most eager users, since JDBC4 is always in the trunk, and even if we remove JDBC4, we can't rollback svn and undo what we've done. -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway
Re: 10.2 plans (was Re: 10.2 licensing issue)
Jean T. Anderson wrote: Kathey Marsden wrote: Kathy Saunders wrote: I'm not sure what decisive action we can take prior to a 10.2 release. We've asked the user community to test with some response, but not a lot. The users will only do their testing when they are motivated. My proposal is that we embark on a three week motivation campaign until October 3. snipped We don't have a release candidate yet -- don't we need to get some ducks in a row? (1) Declare consensus on how to proceed with the release. I believe I hear general agreement that Dan's Plan B is the preferred path: Option A - Source only release with JDBC 4.0 based on proposed final draft Derby 10.2 release is source only, no pre-compiled jars, removes the dependency on the Mustang download. Option B - Release pre-compiled jars without JDBC 4.0 optional build Option A plus pre-compiled jars without JDBC 4.0, already supported by just compiling without a Java SE 6/Mustang JDK. Are there any objections? If not, I recommend moving on to #2. (2) Produce an actual release candidate for people to test. The 10.2.1.3-beta is not a releasable candidate because it was built with jdk16 (correct?) and I assume that Rick might want to mega-merge in any changes since the last mega-merge. Is that a good/bad assumption, Rick? Hi Jean, I will definitely want to mega-merge before building a new beta candidate. The following issues prevent us from building a release candidate, however: 1) We need to wrap up or downgrade the urgency of the remaining Urgent issues (http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hiderequestId=12311108). 2) As you've described, we need to adjust the user guides to clarify how a customer would see JDBC4 behavior. 3) We need to bundle Release Notes with the distribution. I'm working on this right now. Regards, -Rick The motivation campaign Kathey talks about could be part of this test. I bet there might be some debate over how long that test period should be, but it might be more productive to debate over an actual release candidate. (3) Vote on that release candidate if it seems stable. -jean
Re: 10.2 plans (was Re: 10.2 licensing issue)
Rick Hillegas wrote: ... Hi Jean, I will definitely want to mega-merge before building a new beta candidate. The following issues prevent us from building a release candidate, however: 1) We need to wrap up or downgrade the urgency of the remaining Urgent issues (http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hiderequestId=12311108). 2) As you've described, we need to adjust the user guides to clarify how a customer would see JDBC4 behavior. I'll offer to work issue #2. -jean 3) We need to bundle Release Notes with the distribution. I'm working on this right now. Regards, -Rick
Re: 10.2 plans (was Re: 10.2 licensing issue)
Thanks, Jean! Jean T. Anderson wrote: Rick Hillegas wrote: ... Hi Jean, I will definitely want to mega-merge before building a new beta candidate. The following issues prevent us from building a release candidate, however: 1) We need to wrap up or downgrade the urgency of the remaining Urgent issues (http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hiderequestId=12311108). 2) As you've described, we need to adjust the user guides to clarify how a customer would see JDBC4 behavior. I'll offer to work issue #2. -jean 3) We need to bundle Release Notes with the distribution. I'm working on this right now. Regards, -Rick
Re: 10.2 plans (was Re: 10.2 licensing issue)
Might I suggest we have a very simple build script for building the JDBC4 functionality and adding it to derby.jar and derbyclient.jar, and that this build script be well tested and documented? All you should have to do is set one property indicating where your JDK 6 JAVA_HOME is and you're off and running... Thanks, David Rick Hillegas wrote: Thanks, Jean! Jean T. Anderson wrote: Rick Hillegas wrote: ... Hi Jean, I will definitely want to mega-merge before building a new beta candidate. The following issues prevent us from building a release candidate, however: 1) We need to wrap up or downgrade the urgency of the remaining Urgent issues (http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hiderequestId=12311108). 2) As you've described, we need to adjust the user guides to clarify how a customer would see JDBC4 behavior. I'll offer to work issue #2. -jean 3) We need to bundle Release Notes with the distribution. I'm working on this right now. Regards, -Rick
Re: 10.2 plans (was Re: 10.2 licensing issue)
Andrew McIntyre wrote: Taking this over to derby-dev... On 9/11/06, Kathey Marsden [EMAIL PROTECTED] wrote: Many of these regressions sadly have already made their way into 10.1.3 and therefore are being picked up by users for production. I think we need to notify the user community of the situation, try to get more user input on 10.2 and flush out more regressions. We port fixes to 10.1 to try to get it to a stable state and then release 10.2. Also any ideas anyone has for new optimizer tests would be good and folks could write those. Those are all my ideas for now. It could be that lots of users have tried 10.2 without problems but haven't reported in and then it is just a matter of getting them to speak up. I don't think we should hold up the 10.2 release except for known regressions. I think it's a chicken-and-egg problem. Users aren't motivated to try out the beta, because it's extra time and effort on their part, so you aren't actually informed about regressions until the regression is in a release that people actually try to use. Better to release early so new code gets into actual user's hands so regressions can be flushed out sooner. Regressions happen, and no release is ever go to be perfect (although that would be nice, wouldn't it?). Better to release often so code where regressions have been identified and fixed get into user's hands sooner. I think releasing early and often is an area we as a community, and individually through the tasks we take on for any particular release, could improve. andrew I agree with Andrew, unless there are known regression to be fixed, it is not practical to wait for the users to report if there are any issues with 10.2. Or there need to be some kind of time frame when the beta testing closes. /suresh
Re: 10.2 plans (was Re: 10.2 licensing issue)
Myrna van Lunteren wrote: For what it's worth, my position is somewhere in the middle. I think there are some worrying aspects to some of those optimizer-related regressions. Also, I feel we're still scrambling on 10.2.; still documentation changes are being worked on...Now that in a way some of the pressure to release is off, we need to take another look at changes slated for 10.2.2 and see if there are any that really should go in to make the first release of 10.2 but we've dropped because of lack of time. If we release now, we should focus activities for 10.2.2 with the goal of making it more robust as well as having the jdbc40 support in. Myrna Hi, To clarify my opinions, here's what I'm concerned about: 1 - If there are quality issues that anyone thinks we should fix, then what are those specific issues? Advocate to get them on Rick's list to fix before a release should happen. General concerns about quality at this point are a problem for me as I don't understand what we are to do before we can have a release. I do believe there are regressions out there. I do believe there are regressions in the optimizer specifically because that's difficult code and from other products I've worked on when you make significant changes to the optimizer, you almost always have other issues pop up, and it's not necessarily easy to get them to surface. But, if you continue to hold up a release because of regression concerns, you'll never have one. In my opinion, it's generally time to get this release done, once we have the known significant issues resolved. If we really believe we need more testing, then what is that testing and who is going to do it? Discussion on quality is healthy, but at this point in the release process I believe we need to be specific about what actions or outcome we need to complete the release. 2 - Regarding the Mustang and JDBC 4 issue, my general opinion is that if Mustang is still coming out in October then it may be worth it to continue on our current path and do a release that includes JDBC 4. If Mustang is delayed, then I think it's just time to get 10.2 done to get some of the other good features out there. It's been quite a while since we've had a feature release. Does anyone know the current schedule for Mustang? Kathy
Re: 10.2 plans (was Re: 10.2 licensing issue)
2 - Regarding the Mustang and JDBC 4 issue, my general opinion is that if Mustang is still coming out in October then it may be worth it to continue on our current path and do a release that includes JDBC 4. If Mustang is delayed, then I think it's just time to get 10.2 done to get some of the other good features out there. It's been quite a while since we've had a feature release. Does anyone know the current schedule for Mustang? see http://blogs.sun.com/mr/entry/java_se_6_schedule_update for details on the SE 6 schedule Kathy
Re: 10.2 plans (was Re: 10.2 licensing issue)
Kathy Saunders wrote: Myrna van Lunteren wrote: For what it's worth, my position is somewhere in the middle. I think there are some worrying aspects to some of those optimizer-related regressions. Also, I feel we're still scrambling on 10.2.; still documentation changes are being worked on...Now that in a way some of the pressure to release is off, we need to take another look at changes slated for 10.2.2 and see if there are any that really should go in to make the first release of 10.2 but we've dropped because of lack of time. If we release now, we should focus activities for 10.2.2 with the goal of making it more robust as well as having the jdbc40 support in. Myrna Hi, To clarify my opinions, here's what I'm concerned about: 1 - If there are quality issues that anyone thinks we should fix, then what are those specific issues? Advocate to get them on Rick's list to fix before a release should happen. General concerns about quality at this point are a problem for me as I don't understand what we are to do before we can have a release. I do believe there are regressions out there. I do believe there are regressions in the optimizer specifically because that's difficult code and from other products I've worked on when you make significant changes to the optimizer, you almost always have other issues pop up, and it's not necessarily easy to get them to surface. But, if you continue to hold up a release because of regression concerns, you'll never have one. In my opinion, it's generally time to get this release done, once we have the known significant issues resolved. If we really believe we need more testing, then what is that testing and who is going to do it? Discussion on quality is healthy, but at this point in the release process I believe we need to be specific about what actions or outcome we need to complete the release. 2 - Regarding the Mustang and JDBC 4 issue, my general opinion is that if Mustang is still coming out in October then it may be worth it to continue on our current path and do a release that includes JDBC 4. If Mustang is delayed, then I think it's just time to get 10.2 done to get some of the other good features out there. It's been quite a while since we've had a feature release. Does anyone know the current schedule for Mustang? Kathy The optimizer related regression that I am aware of : DERBY-1633 - fixed DERBY-1777 - Army has a patch submitted DERBY-1806 - from the last comments, unable to replicate. Is there anything else that I am missing ? I would assume DERBY-1777 will get committed soon. So from the above and given the uncertainty of the exact date of JDK 6 shipment, I don't see why we should hold up a 10.2 release. Now another point for discussion is, after 10.2, when Mustang gets released what should be the version for DERBY with the JDBC4 support be called - 10.3 ? -Rajesh
Re: 10.2 plans (was Re: 10.2 licensing issue)
Lance J. Andersen wrote: 2 - Regarding the Mustang and JDBC 4 issue, my general opinion is that if Mustang is still coming out in October then it may be worth it to continue on our current path and do a release that includes JDBC 4. If Mustang is delayed, then I think it's just time to get 10.2 done to get some of the other good features out there. It's been quite a while since we've had a feature release. Does anyone know the current schedule for Mustang? see http://blogs.sun.com/mr/entry/java_se_6_schedule_update for details on the SE 6 schedule Kathy Thank you for the link, Lance. Given these new dates, my vote is to go ahead and release Derby 10.2 without JDBC 4. Kathy
Re: 10.2 plans (was Re: 10.2 licensing issue)
On 9/12/06, Kathy Saunders [EMAIL PROTECTED] wrote: Lance J. Andersen wrote: 2 - Regarding the Mustang and JDBC 4 issue, my general opinion is that if Mustang is still coming out in October then it may be worth it to continue on our current path and do a release that includes JDBC 4. If Mustang is delayed, then I think it's just time to get 10.2 done to get some of the other good features out there. It's been quite a while since we've had a feature release. Does anyone know the current schedule for Mustang? see http://blogs.sun.com/mr/entry/java_se_6_schedule_update for details on the SE 6 schedule Kathy Thank you for the link, Lance. Given these new dates, my vote is to go ahead and release Derby 10.2 without JDBC 4. Kathy I may not have been clear earlier. I vote to also go ahead without JDBC4. Which I guess also means one more round of release candidate-testing. Myrna
Re: 10.2 plans (was Re: 10.2 licensing issue)
Rajesh Kartha wrote: ... lots of good discussion ... Now another point for discussion is, after 10.2, when Mustang gets released what should be the version for DERBY with the JDBC4 support be called - 10.3 ? -Rajesh Hi Rajesh, There seem to be at least two issues here: 1) Release numbering. What should we call the JDBC4-exposing release: 10.2.x or 10.3? Since JDBC4 is a big feature, would it be deceptive to expose it in bug-fix release? 2) Branch management. Suppose we decided to call this JDBC4-exposing release 10.3.. Would it be confusing or would something break if we made the following changes in the 10.2 branch three months hence: a) changed the release identifier from 10.2.x to 10.3 b) made appropriate changes to the documentation Regards, -Rick
Re: 10.2 plans (was Re: 10.2 licensing issue)
Since this is an open-*source* project, we do have other options that seem to have no legal issues to me (IANAL). Option A - Source only release with JDBC 4.0 based on proposed final draft Derby 10.2 release is source only, no pre-compiled jars, removes the dependency on the Mustang download. Option B - Release pre-compiled jars without JDBC 4.0 optional build Option A plus pre-compiled jars without JDBC 4.0, already supported by just compiling without a Java SE 6/Mustang JDK. In both cases the current state of the 10.2 branch is left unchanged wrt JDBC 4.0, ie. no removal of JDBC 4.0 from code or documentation. Dan.
Re: 10.2 plans (was Re: 10.2 licensing issue)
Daniel John Debrunner wrote: Since this is an open-*source* project, we do have other options that seem to have no legal issues to me (IANAL). Option A - Source only release with JDBC 4.0 based on proposed final draft Derby 10.2 release is source only, no pre-compiled jars, removes the dependency on the Mustang download. Option B - Release pre-compiled jars without JDBC 4.0 optional build Option A plus pre-compiled jars without JDBC 4.0, already supported by just compiling without a Java SE 6/Mustang JDK. In both cases the current state of the 10.2 branch is left unchanged wrt JDBC 4.0, ie. no removal of JDBC 4.0 from code or documentation. I think this is brilliant. Just leave the source code as it is but release binaries without JDBC4 (read: don't compile them with JDK 6). Anyone that want to experiment with JDBC4 may of course get the Derby 10.2 source and JDK 6 beta-build x and do whatever seems fit for the experiments. -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway
Re: 10.2 plans (was Re: 10.2 licensing issue)
Bernt M. Johnsen wrote: Daniel John Debrunner wrote: Since this is an open-*source* project, we do have other options that seem to have no legal issues to me (IANAL). Option A - Source only release with JDBC 4.0 based on proposed final draft Derby 10.2 release is source only, no pre-compiled jars, removes the dependency on the Mustang download. Option B - Release pre-compiled jars without JDBC 4.0 optional build Option A plus pre-compiled jars without JDBC 4.0, already supported by just compiling without a Java SE 6/Mustang JDK. In both cases the current state of the 10.2 branch is left unchanged wrt JDBC 4.0, ie. no removal of JDBC 4.0 from code or documentation. I think this is brilliant. Just leave the source code as it is but release binaries without JDBC4 (read: don't compile them with JDK 6). Anyone that want to experiment with JDBC4 may of course get the Derby 10.2 source and JDK 6 beta-build x and do whatever seems fit for the experiments. BTW: IANAL too. -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway
Re: 10.2 plans (was Re: 10.2 licensing issue)
Hi Dan, Daniel John Debrunner wrote: Since this is an open-*source* project, we do have other options that seem to have no legal issues to me (IANAL). Option A - Source only release with JDBC 4.0 based on proposed final draft Derby 10.2 release is source only, no pre-compiled jars, removes the dependency on the Mustang download. This would seem to require that users become developers, at least to the point of creating a development environment. I had an unhappy initial experience as a Derby developer a year ago. Perhaps the situation has gotten better. I recall that setting up a development environment involved a lot of steps and moving parts--fetching various pieces of software from various locations, editting ant configuration files, etc.. I think that may discourage many users. That in turn will limit the commodity testing and feedback which we hope to get from users of the official release. In addition, an uncontrolled build process would very likely complicate bug reporting. For these reasons, I would recommend against this option. Option B - Release pre-compiled jars without JDBC 4.0 optional build Option A plus pre-compiled jars without JDBC 4.0, already supported by just compiling without a Java SE 6/Mustang JDK. I'm afraid I don't understand option (B). How does this differ from option (1)? Are you recommending that we add some top-level build targets so that developers can build jars which contain just the JDBC4 bits for layering on top of official 10.2 jars? In both cases the current state of the 10.2 branch is left unchanged wrt JDBC 4.0, ie. no removal of JDBC 4.0 from code or documentation. Dan. I would certainly welcome a solution which doesn't involve yanking out the JDBC4 documentation! Regards, -Rick
Re: 10.2 plans (was Re: 10.2 licensing issue)
On 9/12/06, Rick Hillegas [EMAIL PROTECTED] wrote: Hi Dan, Daniel John Debrunner wrote: Since this is an open-*source* project, we do have other options that seem to have no legal issues to me (IANAL). Option A - Source only release with JDBC 4.0 based on proposed final draft Derby 10.2 release is source only, no pre-compiled jars, removes the dependency on the Mustang download. This would seem to require that users become developers, at least to the point of creating a development environment. I'm not in favor of this option, but not because I think setting up a build is difficult. I think a lot of users would simply pass on the release if there were not precompiled binaries because they won't go to the trouble if it's not a completely out-of-the-box procedure. Too easy to just go get some other embedded database that's has binaries available. Option B - Release pre-compiled jars without JDBC 4.0 optional build Option A plus pre-compiled jars without JDBC 4.0, already supported by just compiling without a Java SE 6/Mustang JDK. I'm afraid I don't understand option (B). How does this differ from option (1)? With this option the binaries that are shipped do not contain the optional JDBC 4 compiled in, and thus are not compiled against the JDK 1.6 runtime classes or use the JDK 1.6 compiler and are thus unencumbered. i.e. just take the 'jdk16' property out of your ant.properties when you're building the release. The source distribution, because it isn't compiled, is not encumbered by either of these restraints either. I would certainly welcome a solution which doesn't involve yanking out the JDBC4 documentation! If we go with option B (which I think is a great idea, btw) then maybe just add a note for 10.2 about the need to compiling from the source to use the feature and a note about the legal/technical ramifications of using the JDBC 4 features. Once the JDK has shipped, I personally would be ok with doing a 10.2.2 that includes JDBC 4.0 without moving immediately to 10.3. Although, by the time the JDK has shipped, there may be bunch of new features that we may want to release, so maybe 10.3 will be the right thing to do at that point. andrew
Re: 10.2 plans (was Re: 10.2 licensing issue)
A quick chime in. I am not comfortable with a source-only release of 10.2. I think a binary release without JDBC4, plus the source for the JDBC4 functionality for those who want it and are prepared to do a build (e.g. option 2) seems quite reasonable to me. David Bernt M. Johnsen wrote: Rick Hillegas wrote: Hi Dan, Daniel John Debrunner wrote: Since this is an open-*source* project, we do have other options that seem to have no legal issues to me (IANAL). Option A - Source only release with JDBC 4.0 based on proposed final draft Derby 10.2 release is source only, no pre-compiled jars, removes the dependency on the Mustang download. This would seem to require that users become developers, at least to the point of creating a development environment. Well. Derby is *not* an end-user product, so the Derby users are themselves developers. I had an unhappy initial experience as a Derby developer a year ago. Perhaps the situation has gotten better. I recall that setting up a development environment involved a lot of steps and moving parts--fetching various pieces of software from various locations, editting ant configuration files, etc.. I think that may discourage many users. That in turn will limit the commodity testing and feedback which we hope to get from users of the official release. I see your concerns. But I have done this maneouver several times in my career with various open source products (the list is very long, but I started with some platform problems with emacs on Sun386i in the late 80s), and the build process wasn't always smooth (I even once had to edit a files in SunOS /usr/include to make gcc compile). Don't underestimate the Derby users. In addition, an uncontrolled build process would very likely complicate bug reporting. For these reasons, I would recommend against this option. The option will always be there for the most eager users, since JDBC4 is always in the trunk, and even if we remove JDBC4, we can't rollback svn and undo what we've done.
Re: 10.2 plans (was Re: 10.2 licensing issue)
Andrew McIntyre wrote: On 9/12/06, Rick Hillegas [EMAIL PROTECTED] wrote: Daniel John Debrunner wrote: ... Option B - Release pre-compiled jars without JDBC 4.0 optional build Option A plus pre-compiled jars without JDBC 4.0, already supported by just compiling without a Java SE 6/Mustang JDK. I'm afraid I don't understand option (B). How does this differ from option (1)? With this option the binaries that are shipped do not contain the optional JDBC 4 compiled in, and thus are not compiled against the JDK 1.6 runtime classes or use the JDK 1.6 compiler and are thus unencumbered. i.e. just take the 'jdk16' property out of your ant.properties when you're building the release. The source distribution, because it isn't compiled, is not encumbered by either of these restraints either. I would certainly welcome a solution which doesn't involve yanking out the JDBC4 documentation! If we go with option B (which I think is a great idea, btw) then maybe just add a note for 10.2 about the need to compiling from the source to use the feature and a note about the legal/technical ramifications of using the JDBC 4 features. We might be able to avoid most end user confusion (hey! how come this doesn't work with jdbc 4?) by adding a short warning to the half dozen doc pages that reference 4.0 functionality. I think these are mostly: /db/derby/docs/trunk/src/ref/rrefjdbc4_0*.dita Some confusion is inevitable and we'd just deal with it on the user list. Once the JDK has shipped, I personally would be ok with doing a 10.2.2 that includes JDBC 4.0 without moving immediately to 10.3. Although, by the time the JDK has shipped, there may be bunch of new features that we may want to release, so maybe 10.3 will be the right thing to do at that point. I'd also have no problem enabling jdbc 4 in a 10.2.2 release. -jean
Re: 10.2 plans (was Re: 10.2 licensing issue)
Andrew McIntyre wrote: On 9/12/06, Rick Hillegas [EMAIL PROTECTED] wrote: Hi Dan, Daniel John Debrunner wrote: Since this is an open-*source* project, we do have other options that seem to have no legal issues to me (IANAL). Option A - Source only release with JDBC 4.0 based on proposed final draft Derby 10.2 release is source only, no pre-compiled jars, removes the dependency on the Mustang download. This would seem to require that users become developers, at least to the point of creating a development environment. I'm not in favor of this option, but not because I think setting up a build is difficult. I think a lot of users would simply pass on the release if there were not precompiled binaries because they won't go to the trouble if it's not a completely out-of-the-box procedure. Too easy to just go get some other embedded database that's has binaries available. Option B - Release pre-compiled jars without JDBC 4.0 optional build Option A plus pre-compiled jars without JDBC 4.0, already supported by just compiling without a Java SE 6/Mustang JDK. I'm afraid I don't understand option (B). How does this differ from option (1)? With this option the binaries that are shipped do not contain the optional JDBC 4 compiled in, and thus are not compiled against the JDK 1.6 runtime classes or use the JDK 1.6 compiler and are thus unencumbered. i.e. just take the 'jdk16' property out of your ant.properties when you're building the release. The source distribution, because it isn't compiled, is not encumbered by either of these restraints either. I would certainly welcome a solution which doesn't involve yanking out the JDBC4 documentation! If we go with option B (which I think is a great idea, btw) then maybe just add a note for 10.2 about the need to compiling from the source to use the feature and a note about the legal/technical ramifications of using the JDBC 4 features. Thanks, Andrew. I think I now understand that option (B) is option (1) with these changes: i) No need to yank out the JDBC4 documentation ii) Simply add a paragraph to the Release Notes explaining how to compile the JDBC4 bits. Also add a note explaining the legal and compatibility issues. I think we would nevertheless also need the following: iii) Various changes to the documentation to explain that, by default, you will get the JDBC3 implementation if you run your application on JDK 6 but that, by compiling in the JDBC4 bits you can get an encumbered early access JDBC4 implementation. These changes would only have to go into the 10.2 branch and could be removed when we release a JDBC4-enabled version of Derby. I am happy with this solution. Once the JDK has shipped, I personally would be ok with doing a 10.2.2 that includes JDBC 4.0 without moving immediately to 10.3. Although, by the time the JDK has shipped, there may be bunch of new features that we may want to release, so maybe 10.3 will be the right thing to do at that point. I agree that we can probably defer the discussion about release numbering and branch management. Regards, -Rick andrew
Re: 10.2 plans (was Re: 10.2 licensing issue)
On 9/12/06, Daniel John Debrunner [EMAIL PROTECTED] wrote: In both cases the current state of the 10.2 branch is left unchanged wrt JDBC 4.0, ie. no removal of JDBC 4.0 from code or documentation. Dan. If either of these approaches are used, the doc issue needs to be handled carefully. The JDBC 4.0 information will be in the documentation. Even if a statement is put into the Release Notes about this, it is very likely that a user (or 2) will miss the statement about JDBC 4.0 in the Release Notes and run into some problems. Something should also be posted on the Web Pages for Derby as well. I am not entirely comfortable with leaving a feature in the documentation that is not being delivered. If the docs are left as is, then I would prefer a feature release 10.3 when we formally support JDBC 4.0. -- Laura Stewart
Re: 10.2 plans (was Re: 10.2 licensing issue)
I am impressed with Dan's Option B. It solves all of my issues (IANAL). 1. Users get binary release of 10.2 features (except for JDBC4) out of the box. 2. Users who want to play developer get to build the sources to expose JDBC4 with their own copy of JDK 1.6 which encumbers themselves. 3. And since we are already shipping it in source form, we can vote to add JDBC4 binary in a maintenance release (once JDK 1.6 goes final) by recompiling with a different flag (jdk16) in the build process (and testing, testing, testing).There is clearly work to do now to adapt the 10.2 bits to match the proposal, but much less than other options we've recently looked at.Craig Craig Russell[EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: 10.2 plans (was Re: 10.2 licensing issue)
Laura Stewart wrote: On 9/12/06, Daniel John Debrunner [EMAIL PROTECTED] wrote: In both cases the current state of the 10.2 branch is left unchanged wrt JDBC 4.0, ie. no removal of JDBC 4.0 from code or documentation. If either of these approaches are used, the doc issue needs to be handled carefully. The JDBC 4.0 information will be in the documentation. Even if a statement is put into the Release Notes about this, it is very likely that a user (or 2) will miss the statement about JDBC 4.0 in the Release Notes and run into some problems. So let's nail down the doc problem. I think https://issues.apache.org/jira/browse/DERBY-1271 summarizes the changes. Scroll down past the description to the comments section. You should see a tab marked Subversion Commits. Click on that and you'll see all the files that were changed for JDBC 4. It looks like 6 files were added to the Reference Guide specifically for the new JDBC 4.0 features: rrefjdbc4_0connection.dita rrefjdbc4_0sqlexception.dita rrefjdbc4_0databaseMetaData.dita rrefjdbc4_0statement.dita rrefjdbc4_0dataSource.dita rrefjdbc4_0summary.dita What if we were to add a short notice to each file along the lines of (the specific wording would need to get nailed down): This is new jdbc 4 functionality that is only available to developers who build Derby with jdk16. Are there any other key files that would also need a notice? --I'm willing to help put these notices in (and pull them back out when they are no longer needed). Something should also be posted on the Web Pages for Derby as well. I am not entirely comfortable with leaving a feature in the documentation that is not being delivered. But the source will be there, so the documentation would be useful for anyone who wants to build Derby with jdk16. If the docs are left as is, then I would prefer a feature release 10.3 when we formally support JDBC 4.0. I disagree because developers will already have that functionality if they choose to build Derby themselves. The 10.2 maintenance release would just need to be recompiled with jdk16 to enable that jdbc 4 functionality for users. I do agree that we need to do what we can to avoid confusion. -jean
Re: 10.2 plans (was Re: 10.2 licensing issue)
Kathy Saunders wrote: I'm not sure what decisive action we can take prior to a 10.2 release. We've asked the user community to test with some response, but not a lot. The users will only do their testing when they are motivated. My proposal is that we embark on a three week motivation campaign until October 3. I know it is late to start on this but I would really like to try and rattle the bushes and think we can get more interest. Then wait for a steady state of a week without any new regressions. If there have been no regressions filed for a week as of October 3, we call a vote. Does that sound ok? This is what I propose in terms of beta marketing. - Come up with a list of ideas of beta things to try that might pop issues. For example Army's list [1] is very good. Specific risk areas that might be of interest to users. I will start a wiki page where they can be added. - Folks can send out targeted beta test requests to as many users as they can where they work and elsewhere that use Derby. Best to ask them to try something specific that might interest them and of course ask them to ask two more, chain letter style #:) - Get the beta announcement prominently on the download site with a link to the beta. with the pre-release upgrade option. Is this legal and ok? I sent beta out to some interested users a while back and need to pester them and collect feedback and will try to contact more. Rick, did you contact the users on UsesOfDerby. I noticed you added email addresses. Did you contact these folks?What Apache lists would be good to query about trying Derby? Sorry for the late start on this, but I am ready to jump on this effort myself and hope others are motivated to do it as well. Kathey
Re: 10.2 plans (was Re: 10.2 licensing issue)
Kathey Marsden wrote: Kathy Saunders wrote: I'm not sure what decisive action we can take prior to a 10.2 release. We've asked the user community to test with some response, but not a lot. The users will only do their testing when they are motivated. My proposal is that we embark on a three week motivation campaign until October 3. snipped We don't have a release candidate yet -- don't we need to get some ducks in a row? (1) Declare consensus on how to proceed with the release. I believe I hear general agreement that Dan's Plan B is the preferred path: Option A - Source only release with JDBC 4.0 based on proposed final draft Derby 10.2 release is source only, no pre-compiled jars, removes the dependency on the Mustang download. Option B - Release pre-compiled jars without JDBC 4.0 optional build Option A plus pre-compiled jars without JDBC 4.0, already supported by just compiling without a Java SE 6/Mustang JDK. Are there any objections? If not, I recommend moving on to #2. (2) Produce an actual release candidate for people to test. The 10.2.1.3-beta is not a releasable candidate because it was built with jdk16 (correct?) and I assume that Rick might want to mega-merge in any changes since the last mega-merge. Is that a good/bad assumption, Rick? The motivation campaign Kathey talks about could be part of this test. I bet there might be some debate over how long that test period should be, but it might be more productive to debate over an actual release candidate. (3) Vote on that release candidate if it seems stable. -jean
10.2 plans (was Re: 10.2 licensing issue)
Taking this over to derby-dev... On 9/11/06, Kathey Marsden [EMAIL PROTECTED] wrote: Many of these regressions sadly have already made their way into 10.1.3 and therefore are being picked up by users for production. I think we need to notify the user community of the situation, try to get more user input on 10.2 and flush out more regressions. We port fixes to 10.1 to try to get it to a stable state and then release 10.2. Also any ideas anyone has for new optimizer tests would be good and folks could write those. Those are all my ideas for now. It could be that lots of users have tried 10.2 without problems but haven't reported in and then it is just a matter of getting them to speak up. I don't think we should hold up the 10.2 release except for known regressions. I think it's a chicken-and-egg problem. Users aren't motivated to try out the beta, because it's extra time and effort on their part, so you aren't actually informed about regressions until the regression is in a release that people actually try to use. Better to release early so new code gets into actual user's hands so regressions can be flushed out sooner. Regressions happen, and no release is ever go to be perfect (although that would be nice, wouldn't it?). Better to release often so code where regressions have been identified and fixed get into user's hands sooner. I think releasing early and often is an area we as a community, and individually through the tasks we take on for any particular release, could improve. andrew
Re: 10.2 plans (was Re: 10.2 licensing issue)
Andrew McIntyre wrote: Taking this over to derby-dev... On 9/11/06, Kathey Marsden [EMAIL PROTECTED] wrote: Many of these regressions sadly have already made their way into 10.1.3 and therefore are being picked up by users for production. I think we need to notify the user community of the situation, try to get more user input on 10.2 and flush out more regressions. We port fixes to 10.1 to try to get it to a stable state and then release 10.2. Also any ideas anyone has for new optimizer tests would be good and folks could write those. Those are all my ideas for now. It could be that lots of users have tried 10.2 without problems but haven't reported in and then it is just a matter of getting them to speak up. I don't think we should hold up the 10.2 release except for known regressions. I think it's a chicken-and-egg problem. Users aren't motivated to try out the beta, because it's extra time and effort on their part, so you aren't actually informed about regressions until the regression is in a release that people actually try to use. Better to release early so new code gets into actual user's hands so regressions can be flushed out sooner. Regressions happen, and no release is ever go to be perfect (although that would be nice, wouldn't it?). Better to release often so code where regressions have been identified and fixed get into user's hands sooner. I think releasing early and often is an area we as a community, and individually through the tasks we take on for any particular release, could improve. andrew I second Andrew's comments. Kathey has been a great quality advocate for Derby, and I hope will continue to speak up. But, in this case, I'm not sure what decisive action we can take prior to a 10.2 release. We've asked the user community to test with some response, but not a lot. The users will only do their testing when they are motivated. I think it's excellent that users were invited to do testing, and I see that Kathey posted again asking for more testing, which is great. However, unless we have a specific regression or action that needs to be taken, I don't believe it makes sense to talk about holding up Derby 10.2 for quality issues. Let's get it out there, and if there are regressions (in my experience working in technical support for commercial products for 15 years, there are always regressions), we can get new builds and/or a maintenance release out. On the other hand, if we have any specific quality issues that should be addressed prior to a 10.2 release, let's talk about those. Kathy
