Re: Proposal for 10.2 release schedule
Hi Mike, Some responses follow. Regards-Rick Mike Matrigali wrote: Rick Hillegas wrote: Thanks, Kathy. I think I'm getting the message that the following would be an acceptable and more traditional schedule: August 10 : Last feature work commits August 11 : First release candidate generated August 24 : Second release candidate generated September 7: Third and hopefully last release candidate generated September 15: Targetted end of voting on release candidates Is this a realistic schedule or is it still too aggressive? Thanks, -Rick What kind of changes are you going to include in each of the release candidates (ie. all checkins to the branch, or some subset of those changes -- I think in the past andrew has used either)? The above seems reasonable assuming that the only changes are bug fixes addressing regressions shown up by testing. I assume it is reasonable to accept all additional tests during the release testing period. I was hoping that only bug fixes would go into the branch and that each release candidate would just roll up those bug fixes. The release candidates would be snapshots of the branch at the time the candidates are cut. I hope this is reasonable. I believe some of the features were already originally planning on an august 15 or later date, and have adjusted to an august 10 date. Some definitely won't make it with an earlier code freeze. What is the assumption about bug fixing of outstanding bugs known before august 10th? Maybe there is a published list of bugs that need to be fixed for a successful release? I need to start compiling this list. Fortunately, Kathey is already forging ahead, raising the priority of suspect bugs. I have been putting off this task until we reach consensus about the date for branching.
Re: Proposal for 10.2 release schedule
Rick Hillegas wrote: Last week, Sun Microsystems announced that it will bundle Derby with the next major release of the reference jdk, Java SE 6, also known as Mustang or jdk1.6. If you download the latest Mustang build, you will see that it contains our Derby 10.2.0.3 snapshot in the db directory parallel to lib and bin. This is big news. It means that over the course of the next year, Derby will turn up on the desktops of millions of developers. Hopefully, Derby's user and developer communities will both grow dramatically. I would like to support this bundling. Note that Mustang will need our vetted 10.2 release candidate by September 15 so that they can QA it. This is expected to take about 5 weeks, after which Mustang should go GA in late October. The JCP requires that our JDBC4-exposing release can not be generally available until the JDBC4 specification is finalized, which happens when Mustang is generally available. Until that date, this means that our final, vetted release candidate can not be officially stamped as GA and we can not promote it to the various Apache mirrors. Here are proposed dates for 10.2 milestones: August 10 - Feature work committed. 10.2 branch created. August 24 - Last day to commit changes for 10.2 August 25 - Begin vetting 10.2 release candidate September 15 - Target date for finishing the voting on Derby 10.2 End of October - Expected GA of JDBC4 with Mustang End of October - GA of Derby 10.2. Release promoted to Apache mirrors. Are this proposal and its dates reasonable? Hi Rick, On careful review of the dates you posted, it looks like the time frame for testing is just about 3 weeks (Aug 25 - Sept 15). 10.2 being a major release with lots of new features/fixes, we need to make sure there is enough time for the community to test the release and 3 weeks sure seems less. My experience during all the previous releases of Derby is that we invariably had multiple release candidates - hence the 10.2 testing time frame needs to take this into account. I suggest one of the following two: 1) Keep the date to complete voting for Derby 10.2 as Sept 15: To achieve this, we move the last day to commit changes early, which would mean: August 10 - Last day to commit changes for 10.2 August 11 - Release Candidate 1 ready for testing September 15 - Target date for finishing the voting on Derby 10.2 2) Push the date to complete voting for Derby 10.2 to Oct 2: August 24 - Last day to commit changes for 10.2 August 25 - Begin vetting 10.2 release candidate Oct 2nd - Target date for finishing the voting on Derby 10.2 This will give us about 5 weeks in both the cases, within which we can provision for RC2 if needed. Let me know what you think. Regards, Rajesh
Re: Proposal for 10.2 release schedule
Thanks, Rajesh. In your scheme, when should feature work on 10.2 wrap up? I had budgeted 2 weeks between the end of feature work and the first release candidate. Is that overkill? Should we propose that feature work wraps up by, say, July 27? Rajesh Kartha wrote: Rick Hillegas wrote: Last week, Sun Microsystems announced that it will bundle Derby with the next major release of the reference jdk, Java SE 6, also known as Mustang or jdk1.6. If you download the latest Mustang build, you will see that it contains our Derby 10.2.0.3 snapshot in the db directory parallel to lib and bin. This is big news. It means that over the course of the next year, Derby will turn up on the desktops of millions of developers. Hopefully, Derby's user and developer communities will both grow dramatically. I would like to support this bundling. Note that Mustang will need our vetted 10.2 release candidate by September 15 so that they can QA it. This is expected to take about 5 weeks, after which Mustang should go GA in late October. The JCP requires that our JDBC4-exposing release can not be generally available until the JDBC4 specification is finalized, which happens when Mustang is generally available. Until that date, this means that our final, vetted release candidate can not be officially stamped as GA and we can not promote it to the various Apache mirrors. Here are proposed dates for 10.2 milestones: August 10 - Feature work committed. 10.2 branch created. August 24 - Last day to commit changes for 10.2 August 25 - Begin vetting 10.2 release candidate September 15 - Target date for finishing the voting on Derby 10.2 End of October - Expected GA of JDBC4 with Mustang End of October - GA of Derby 10.2. Release promoted to Apache mirrors. Are this proposal and its dates reasonable? Hi Rick, On careful review of the dates you posted, it looks like the time frame for testing is just about 3 weeks (Aug 25 - Sept 15). 10.2 being a major release with lots of new features/fixes, we need to make sure there is enough time for the community to test the release and 3 weeks sure seems less. My experience during all the previous releases of Derby is that we invariably had multiple release candidates - hence the 10.2 testing time frame needs to take this into account. I suggest one of the following two: 1) Keep the date to complete voting for Derby 10.2 as Sept 15: To achieve this, we move the last day to commit changes early, which would mean: August 10 - Last day to commit changes for 10.2 August 11 - Release Candidate 1 ready for testing September 15 - Target date for finishing the voting on Derby 10.2 2) Push the date to complete voting for Derby 10.2 to Oct 2: August 24 - Last day to commit changes for 10.2 August 25 - Begin vetting 10.2 release candidate Oct 2nd - Target date for finishing the voting on Derby 10.2 This will give us about 5 weeks in both the cases, within which we can provision for RC2 if needed. Let me know what you think. Regards, Rajesh
Re: Proposal for 10.2 release schedule
Rick Hillegas wrote: Thanks, Rajesh. In your scheme, when should feature work on 10.2 wrap up? I had budgeted 2 weeks between the end of feature work and the first release candidate. Is that overkill? Should we propose that feature work wraps up by, say, July 27? Do we need to have a feature wrap up and then time to do more development? Can't we just say that all planned work--features, bug fixes, etc. should be done by August 10? Then you could post the first RC on August 11 or shortly after that. It's true that feature check-ins might cause some bugs that need to be dealt with, but those can be dealt with in RC2 if need be. Kathy Rajesh Kartha wrote: Rick Hillegas wrote: Last week, Sun Microsystems announced that it will bundle Derby with the next major release of the reference jdk, Java SE 6, also known as Mustang or jdk1.6. If you download the latest Mustang build, you will see that it contains our Derby 10.2.0.3 snapshot in the db directory parallel to lib and bin. This is big news. It means that over the course of the next year, Derby will turn up on the desktops of millions of developers. Hopefully, Derby's user and developer communities will both grow dramatically. I would like to support this bundling. Note that Mustang will need our vetted 10.2 release candidate by September 15 so that they can QA it. This is expected to take about 5 weeks, after which Mustang should go GA in late October. The JCP requires that our JDBC4-exposing release can not be generally available until the JDBC4 specification is finalized, which happens when Mustang is generally available. Until that date, this means that our final, vetted release candidate can not be officially stamped as GA and we can not promote it to the various Apache mirrors. Here are proposed dates for 10.2 milestones: August 10 - Feature work committed. 10.2 branch created. August 24 - Last day to commit changes for 10.2 August 25 - Begin vetting 10.2 release candidate September 15 - Target date for finishing the voting on Derby 10.2 End of October - Expected GA of JDBC4 with Mustang End of October - GA of Derby 10.2. Release promoted to Apache mirrors. Are this proposal and its dates reasonable? Hi Rick, On careful review of the dates you posted, it looks like the time frame for testing is just about 3 weeks (Aug 25 - Sept 15). 10.2 being a major release with lots of new features/fixes, we need to make sure there is enough time for the community to test the release and 3 weeks sure seems less. My experience during all the previous releases of Derby is that we invariably had multiple release candidates - hence the 10.2 testing time frame needs to take this into account. I suggest one of the following two: 1) Keep the date to complete voting for Derby 10.2 as Sept 15: To achieve this, we move the last day to commit changes early, which would mean:August 10 - Last day to commit changes for 10.2 August 11 - Release Candidate 1 ready for testing September 15 - Target date for finishing the voting on Derby 10.2 2) Push the date to complete voting for Derby 10.2 to Oct 2: August 24 - Last day to commit changes for 10.2 August 25 - Begin vetting 10.2 release candidate Oct 2nd - Target date for finishing the voting on Derby 10.2 This will give us about 5 weeks in both the cases, within which we can provision for RC2 if needed. Let me know what you think. Regards, Rajesh
Re: Proposal for 10.2 release schedule
Thanks, Kathy. I think I'm getting the message that the following would be an acceptable and more traditional schedule: August 10 : Last feature work commits August 11 : First release candidate generated August 24 : Second release candidate generated September 7: Third and hopefully last release candidate generated September 15: Targetted end of voting on release candidates Is this a realistic schedule or is it still too aggressive? Thanks, -Rick Kathy Saunders wrote: Rick Hillegas wrote: Thanks, Rajesh. In your scheme, when should feature work on 10.2 wrap up? I had budgeted 2 weeks between the end of feature work and the first release candidate. Is that overkill? Should we propose that feature work wraps up by, say, July 27? Do we need to have a feature wrap up and then time to do more development? Can't we just say that all planned work--features, bug fixes, etc. should be done by August 10? Then you could post the first RC on August 11 or shortly after that. It's true that feature check-ins might cause some bugs that need to be dealt with, but those can be dealt with in RC2 if need be. Kathy Rajesh Kartha wrote: Rick Hillegas wrote: Last week, Sun Microsystems announced that it will bundle Derby with the next major release of the reference jdk, Java SE 6, also known as Mustang or jdk1.6. If you download the latest Mustang build, you will see that it contains our Derby 10.2.0.3 snapshot in the db directory parallel to lib and bin. This is big news. It means that over the course of the next year, Derby will turn up on the desktops of millions of developers. Hopefully, Derby's user and developer communities will both grow dramatically. I would like to support this bundling. Note that Mustang will need our vetted 10.2 release candidate by September 15 so that they can QA it. This is expected to take about 5 weeks, after which Mustang should go GA in late October. The JCP requires that our JDBC4-exposing release can not be generally available until the JDBC4 specification is finalized, which happens when Mustang is generally available. Until that date, this means that our final, vetted release candidate can not be officially stamped as GA and we can not promote it to the various Apache mirrors. Here are proposed dates for 10.2 milestones: August 10 - Feature work committed. 10.2 branch created. August 24 - Last day to commit changes for 10.2 August 25 - Begin vetting 10.2 release candidate September 15 - Target date for finishing the voting on Derby 10.2 End of October - Expected GA of JDBC4 with Mustang End of October - GA of Derby 10.2. Release promoted to Apache mirrors. Are this proposal and its dates reasonable? Hi Rick, On careful review of the dates you posted, it looks like the time frame for testing is just about 3 weeks (Aug 25 - Sept 15). 10.2 being a major release with lots of new features/fixes, we need to make sure there is enough time for the community to test the release and 3 weeks sure seems less. My experience during all the previous releases of Derby is that we invariably had multiple release candidates - hence the 10.2 testing time frame needs to take this into account. I suggest one of the following two: 1) Keep the date to complete voting for Derby 10.2 as Sept 15: To achieve this, we move the last day to commit changes early, which would mean:August 10 - Last day to commit changes for 10.2 August 11 - Release Candidate 1 ready for testing September 15 - Target date for finishing the voting on Derby 10.2 2) Push the date to complete voting for Derby 10.2 to Oct 2: August 24 - Last day to commit changes for 10.2 August 25 - Begin vetting 10.2 release candidate Oct 2nd - Target date for finishing the voting on Derby 10.2 This will give us about 5 weeks in both the cases, within which we can provision for RC2 if needed. Let me know what you think. Regards, Rajesh
Re: Proposal for 10.2 release schedule
Rick Hillegas wrote: Thanks, Kathy. I think I'm getting the message that the following would be an acceptable and more traditional schedule: August 10 : Last feature work commits August 11 : First release candidate generated August 24 : Second release candidate generated September 7: Third and hopefully last release candidate generated September 15: Targetted end of voting on release candidates Is this a realistic schedule or is it still too aggressive? Thanks, -Rick In my opinion that is a reasonable schedule. Of course, number of release candidates and final dates are dependent on the quality of the code. But, based on what I've seen with Derby releases so far, this timeframe seems like it can work. Hopefully the licensing issues will be resolved prior to August 10 as well. Kathy Saunders wrote: Rick Hillegas wrote: Thanks, Rajesh. In your scheme, when should feature work on 10.2 wrap up? I had budgeted 2 weeks between the end of feature work and the first release candidate. Is that overkill? Should we propose that feature work wraps up by, say, July 27? Do we need to have a feature wrap up and then time to do more development? Can't we just say that all planned work--features, bug fixes, etc. should be done by August 10? Then you could post the first RC on August 11 or shortly after that. It's true that feature check-ins might cause some bugs that need to be dealt with, but those can be dealt with in RC2 if need be. Kathy Rajesh Kartha wrote: Rick Hillegas wrote: Last week, Sun Microsystems announced that it will bundle Derby with the next major release of the reference jdk, Java SE 6, also known as Mustang or jdk1.6. If you download the latest Mustang build, you will see that it contains our Derby 10.2.0.3 snapshot in the db directory parallel to lib and bin. This is big news. It means that over the course of the next year, Derby will turn up on the desktops of millions of developers. Hopefully, Derby's user and developer communities will both grow dramatically. I would like to support this bundling. Note that Mustang will need our vetted 10.2 release candidate by September 15 so that they can QA it. This is expected to take about 5 weeks, after which Mustang should go GA in late October. The JCP requires that our JDBC4-exposing release can not be generally available until the JDBC4 specification is finalized, which happens when Mustang is generally available. Until that date, this means that our final, vetted release candidate can not be officially stamped as GA and we can not promote it to the various Apache mirrors. Here are proposed dates for 10.2 milestones: August 10 - Feature work committed. 10.2 branch created. August 24 - Last day to commit changes for 10.2 August 25 - Begin vetting 10.2 release candidate September 15 - Target date for finishing the voting on Derby 10.2 End of October - Expected GA of JDBC4 with Mustang End of October - GA of Derby 10.2. Release promoted to Apache mirrors. Are this proposal and its dates reasonable? Hi Rick, On careful review of the dates you posted, it looks like the time frame for testing is just about 3 weeks (Aug 25 - Sept 15). 10.2 being a major release with lots of new features/fixes, we need to make sure there is enough time for the community to test the release and 3 weeks sure seems less. My experience during all the previous releases of Derby is that we invariably had multiple release candidates - hence the 10.2 testing time frame needs to take this into account. I suggest one of the following two: 1) Keep the date to complete voting for Derby 10.2 as Sept 15: To achieve this, we move the last day to commit changes early, which would mean:August 10 - Last day to commit changes for 10.2 August 11 - Release Candidate 1 ready for testing September 15 - Target date for finishing the voting on Derby 10.2 2) Push the date to complete voting for Derby 10.2 to Oct 2: August 24 - Last day to commit changes for 10.2 August 25 - Begin vetting 10.2 release candidate Oct 2nd - Target date for finishing the voting on Derby 10.2 This will give us about 5 weeks in both the cases, within which we can provision for RC2 if needed. Let me know what you think. Regards, Rajesh
Re: Proposal for 10.2 release schedule
Kathy Saunders wrote: Rick Hillegas wrote: Thanks, Kathy. I think I'm getting the message that the following would be an acceptable and more traditional schedule: August 10 : Last feature work commits August 11 : First release candidate generated August 24 : Second release candidate generated September 7: Third and hopefully last release candidate generated September 15: Targetted end of voting on release candidates Is this a realistic schedule or is it still too aggressive? Thanks, -Rick In my opinion that is a reasonable schedule. Of course, number of release candidates and final dates are dependent on the quality of the code. But, based on what I've seen with Derby releases so far, this timeframe seems like it can work. Hopefully the licensing issues will be resolved prior to August 10 as well. A license that allows creating the release candidate must be in place before the release candidate is made available. Lance, how do these dates work from a licensing perspective? -jean
Re: Proposal for 10.2 release schedule
Rick Hillegas wrote: Thanks, Kathy. I think I'm getting the message that the following would be an acceptable and more traditional schedule: August 10 : Last feature work commits August 11 : First release candidate generated August 24 : Second release candidate generated September 7: Third and hopefully last release candidate generated September 15: Targetted end of voting on release candidates Is this a realistic schedule or is it still too aggressive? Thanks, -Rick What kind of changes are you going to include in each of the release candidates (ie. all checkins to the branch, or some subset of those changes -- I think in the past andrew has used either)? The above seems reasonable assuming that the only changes are bug fixes addressing regressions shown up by testing. I assume it is reasonable to accept all additional tests during the release testing period. I believe some of the features were already originally planning on an august 15 or later date, and have adjusted to an august 10 date. Some definitely won't make it with an earlier code freeze. What is the assumption about bug fixing of outstanding bugs known before august 10th? Maybe there is a published list of bugs that need to be fixed for a successful release?
Re: Proposal for 10.2 release schedule
Mike Matrigali wrote: Rick Hillegas wrote: Thanks, Kathy. I think I'm getting the message that the following would be an acceptable and more traditional schedule: August 10 : Last feature work commits August 11 : First release candidate generated August 24 : Second release candidate generated September 7: Third and hopefully last release candidate generated September 15: Targetted end of voting on release candidates Is this a realistic schedule or is it still too aggressive? Thanks, -Rick What kind of changes are you going to include in each of the release candidates (ie. all checkins to the branch, or some subset of those changes -- I think in the past andrew has used either)? The above seems reasonable assuming that the only changes are bug fixes addressing regressions shown up by testing. I assume it is reasonable to accept all additional tests during the release testing period. I believe some of the features were already originally planning on an august 15 or later date, and have adjusted to an august 10 date. Some definitely won't make it with an earlier code freeze. There's no code freeze per se on ASF projects. The release manager decides what changes should make it into a release. Good info for the httpd project gets referenced by many: http://httpd.apache.org/dev/release.html Let's repeat that: an impending release can not affect development of the project. It is the RM's responsibility to identify what changes should make it into the release. The RM may have an intermediate tag, so the RM can merge in or reject changes as they are committed to the repository's HEAD. Committers may voluntarily refrain from committing patches if they wish to ease the burden on the RM, but they are under no obligation to do so. This is one reason why we recommend that the RMs have plenty of time on their hands - they may have to deal with a rapidly changing target. It's not an easy job. I just get a little worried when I hear the words code freeze. I think a better phrase would be target date. After that date developers can continue developing and it's up to the release manager to include that work (or not). -jean
Re: Proposal for 10.2 release schedule
Jean T. Anderson wrote: I believe some of the features were already originally planning on an august 15 or later date, and have adjusted to an august 10 date. Some definitely won't make it with an earlier code freeze. There's no code freeze per se on ASF projects. sorry, I never meant to imply a code freeze - I agree that there should not be a freeze. Branching the code earlier gives the release and developers what they need. And in the branch we should not freeze, though it is nice to either give the release coordinator a chance to bump the release id in the branch, or to do so your self as was done with the 10.1.3 release. I meant that features that are being targeted for the 10.2 relese may not make the proposed branch date.
Proposal for 10.2 release schedule
Last week, Sun Microsystems announced that it will bundle Derby with the next major release of the reference jdk, Java SE 6, also known as Mustang or jdk1.6. If you download the latest Mustang build, you will see that it contains our Derby 10.2.0.3 snapshot in the db directory parallel to lib and bin. This is big news. It means that over the course of the next year, Derby will turn up on the desktops of millions of developers. Hopefully, Derby's user and developer communities will both grow dramatically. I would like to support this bundling. Note that Mustang will need our vetted 10.2 release candidate by September 15 so that they can QA it. This is expected to take about 5 weeks, after which Mustang should go GA in late October. The JCP requires that our JDBC4-exposing release can not be generally available until the JDBC4 specification is finalized, which happens when Mustang is generally available. Until that date, this means that our final, vetted release candidate can not be officially stamped as GA and we can not promote it to the various Apache mirrors. Here are proposed dates for 10.2 milestones: August 10 - Feature work committed. 10.2 branch created. August 24 - Last day to commit changes for 10.2 August 25 - Begin vetting 10.2 release candidate September 15 - Target date for finishing the voting on Derby 10.2 End of October - Expected GA of JDBC4 with Mustang End of October - GA of Derby 10.2. Release promoted to Apache mirrors. Are this proposal and its dates reasonable?
Re: Proposal for 10.2 release schedule
Rick Hillegas wrote: The JCP requires that our JDBC4-exposing release can not be generally available until the JDBC4 specification is finalized. Is this something that the Derby community is bound to? Here are proposed dates for 10.2 milestones: August 10 - Feature work committed. 10.2 branch created. August 24 - Last day to commit changes for 10.2 August 25 - Begin vetting 10.2 release candidate September 15 - Target date for finishing the voting on Derby 10.2 What happens between September 15 and End of October on the 10.2 branch? Does bug fixing and work on 10.2.1 begin? If we fix critical bugs during that time in the 10.2 branch can't they go into the release end of October? End of October - Expected GA of JDBC4 with Mustang End of October - GA of Derby 10.2. Release promoted to Apache mirrors.
Re: Proposal for 10.2 release schedule
Hi Kathey, Thanks for raising these issues. Here are some clarifications. Regards, -Rick Kathey Marsden wrote: Rick Hillegas wrote: The JCP requires that our JDBC4-exposing release can not be generally available until the JDBC4 specification is finalized. Is this something that the Derby community is bound to? The JCP rules are the license you accept when you publish a GA implementation of a JSR. In our case this is JSR 221, which governs JDBC4. The Derby community accepts this license by exposing a GA implementation of JDBC4 in release 10.2. Here are proposed dates for 10.2 milestones: August 10 - Feature work committed. 10.2 branch created. August 24 - Last day to commit changes for 10.2 August 25 - Begin vetting 10.2 release candidate September 15 - Target date for finishing the voting on Derby 10.2 What happens between September 15 and End of October on the 10.2 branch? Between September 15 and the end of October, the vetted 10.2 release candidate is still available to anyone who needs it, just as the 10.1.3 release candidate is available right now. Does bug fixing and work on 10.2.1 begin? Forgive me for being pedantic about release numbers. I think that the first release cut off the 10.2 branch will be called 10.2.1.0. I think that you are asking about bug fixing for the second release cut off the 10.2 branch, which would be 10.2.2.0. I think that we can begin putting more bug fixes into the 10.2 branch as soon as we produce the first 10.2 release candidate. So that would be mid-September. If we fix critical bugs during that time in the 10.2 branch can't they go into the release end of October? Suppose we were able to publish the 10.2 release candidate (make it GA) right after we vetted it in mid-September. When would you want to produce the follow-on bug fix release? At the end of October? A couple months later? We could do either. The community may want to defer the follow-on bug fix release for a couple months. That would give us time to collect more feedback from users of the published, GA release. However, we could release early, release often and produce another release from the 10.2 branch at the end of October. End of October - Expected GA of JDBC4 with Mustang End of October - GA of Derby 10.2. Release promoted to Apache mirrors.
Re: Proposal for 10.2 release schedule
Rick Hillegas wrote: Last week, Sun Microsystems announced that it will bundle Derby with the next major release of the reference jdk, Java SE 6, also known as Mustang or jdk1.6. To be precise, Sun Microsystems announced that it will bundle Java DB with Mustang. http://biz.yahoo.com/prnews/060621/sfw063.html?.v=66 Dan.
Re: Proposal for 10.2 release schedule
Rick Hillegas wrote: Kathey Marsden wrote: Rick Hillegas wrote: What happens between September 15 and End of October on the 10.2 branch? If we fix critical bugs during that time in the 10.2 branch can't they go into the release end of October? They should be able to. Since we won't have had a GA release (JCP rules) until Mustang ships, it seems any critical bug that we find and fix between Sep 15th and Mustang shipping has the potential to require a new release candidate and new vote. Could even be a database format change. Suppose we were able to publish the 10.2 release candidate (make it GA) right after we vetted it in mid-September. When would you want to produce the follow-on bug fix release? At the end of October? A couple months later? We could do either. The community may want to defer the follow-on bug fix release for a couple months. That would give us time to collect more feedback from users of the published, GA release. However, we could release early, release often and produce another release from the 10.2 branch at the end of October. Not sure I understand the point of this paragraph. I thought the JCP rules mean we can't make 10.2 GA in mid-Sep, thus it seems to be a hypothetical impossible situation. Dan.
Re: Proposal for 10.2 release schedule
Rick Hillegas wrote: Hi Dan, Thanks for your comments. Some further remarks follow. Regards, -Rick Daniel John Debrunner wrote: Rick Hillegas wrote: Kathey Marsden wrote: Rick Hillegas wrote: What happens between September 15 and End of October on the 10.2 branch? If we fix critical bugs during that time in the 10.2 branch can't they go into the release end of October? They should be able to. Since we won't have had a GA release (JCP rules) until Mustang ships, it seems any critical bug that we find and fix between Sep 15th and Mustang shipping has the potential to require a new release candidate and new vote. Could even be a database format change. Let me work out the implications of this. o Mustang would ship with a release candidate which the community rejected. o The community would approve a later release candidate and promote it to GA status. o Bug reports would come in against both the rejected candidate bundled into Mustang and the approved candidate which was promoted to GA status. A couple issues come to mind: o In those bug reports, how would we disambiguate the release candidates? We could bump the last digit of the release identifier after producing the first candidate. Or we could rely on the full version id produced by sysinfo, which contains the subversion revision number. I think we have bumped the fourth version (point) digit after producing a release candidate. That can be done pretty much at any time, so no issues disambiguating release candidates. o The database format change troubles me. What happens if someone creates a database with the rejected release candidate bundled with Mustang? I think we want that database to play well with the approved release candidate which goes GA. The mid-Sep Derby release candidate will be marked alpha or beta (JCP rules) so the databases won't upgrade anyway. Dan.
Re: Proposal for 10.2 release schedule
Daniel John Debrunner wrote: Rick Hillegas wrote: Hi Dan, Thanks for your comments. Some further remarks follow. Regards, -Rick Daniel John Debrunner wrote: Rick Hillegas wrote: Kathey Marsden wrote: Rick Hillegas wrote: What happens between September 15 and End of October on the 10.2 branch? If we fix critical bugs during that time in the 10.2 branch can't they go into the release end of October? They should be able to. Since we won't have had a GA release (JCP rules) until Mustang ships, it seems any critical bug that we find and fix between Sep 15th and Mustang shipping has the potential to require a new release candidate and new vote. Could even be a database format change. Let me work out the implications of this. o Mustang would ship with a release candidate which the community rejected. o The community would approve a later release candidate and promote it to GA status. o Bug reports would come in against both the rejected candidate bundled into Mustang and the approved candidate which was promoted to GA status. A couple issues come to mind: o In those bug reports, how would we disambiguate the release candidates? We could bump the last digit of the release identifier after producing the first candidate. Or we could rely on the full version id produced by sysinfo, which contains the subversion revision number. I think we have bumped the fourth version (point) digit after producing a release candidate. That can be done pretty much at any time, so no issues disambiguating release candidates. o The database format change troubles me. What happens if someone creates a database with the rejected release candidate bundled with Mustang? I think we want that database to play well with the approved release candidate which goes GA. The mid-Sep Derby release candidate will be marked alpha or beta (JCP rules) so the databases won't upgrade anyway. I apologize for creating confusion here. We'd like Mustang to ship with a fully functional Derby, which creates upgradeable databases. So I'm assuming that we turn off the beta marker on the vetted candidate before handing the candidate to Mustang for QA bake-in. Dan.
Re: Proposal for 10.2 release schedule
Rick Hillegas wrote: Daniel John Debrunner wrote: Rick Hillegas wrote: Hi Dan, Thanks for your comments. Some further remarks follow. Regards, -Rick Daniel John Debrunner wrote: Rick Hillegas wrote: Kathey Marsden wrote: Rick Hillegas wrote: What happens between September 15 and End of October on the 10.2 branch? If we fix critical bugs during that time in the 10.2 branch can't they go into the release end of October? They should be able to. Since we won't have had a GA release (JCP rules) until Mustang ships, it seems any critical bug that we find and fix between Sep 15th and Mustang shipping has the potential to require a new release candidate and new vote. Could even be a database format change. Let me work out the implications of this. o Mustang would ship with a release candidate which the community rejected. o The community would approve a later release candidate and promote it to GA status. o Bug reports would come in against both the rejected candidate bundled into Mustang and the approved candidate which was promoted to GA status. A couple issues come to mind: o In those bug reports, how would we disambiguate the release candidates? We could bump the last digit of the release identifier after producing the first candidate. Or we could rely on the full version id produced by sysinfo, which contains the subversion revision number. I think we have bumped the fourth version (point) digit after producing a release candidate. That can be done pretty much at any time, so no issues disambiguating release candidates. o The database format change troubles me. What happens if someone creates a database with the rejected release candidate bundled with Mustang? I think we want that database to play well with the approved release candidate which goes GA. The mid-Sep Derby release candidate will be marked alpha or beta (JCP rules) so the databases won't upgrade anyway. I apologize for creating confusion here. We'd like Mustang to ship with a fully functional Derby, which creates upgradeable databases. So I'm assuming that we turn off the beta marker on the vetted candidate before handing the candidate to Mustang for QA bake-in. Re-reading your comment, I see another issue which I need to clarify. The release candidate is not a GA implementation under the JCP as I understand this process. The candidate does not become GA until we post it on the Apache mirrors and announce, via the Derby website, that it is the latest Derby release.
Re: Proposal for 10.2 release schedule
Rick Hillegas wrote: Daniel John Debrunner wrote: The mid-Sep Derby release candidate will be marked alpha or beta (JCP rules) so the databases won't upgrade anyway. I apologize for creating confusion here. We'd like Mustang to ship with a fully functional Derby, which creates upgradeable databases. So I'm assuming that we turn off the beta marker on the vetted candidate before handing the candidate to Mustang for QA bake-in. Sorry, I don't understand, I thought Derby 10.2 cannot be marked GA until Mustang ships. How can it be marked GA without violating the JCP requirements. Sorry if I'm being dense. Dan.
Re: Proposal for 10.2 release schedule
Ok, this is very tricky. First, I'd like to make sure we're on the same page here about Java DB going into the JDK. I think in general the community thinks it's a good thing for Derby for Java DB to be in the JDK. It gives us great exposure and distribution. I also think the community would probably like it if databases created by the version of Java DB to be upgradable to a subsequent release of Derby, so that users can get the latest and greatest functionality of Derby directly from the Apache web site, or even upgrade to a future release of Cloudscape if they decide to get support from IBM. In order for this to work, we need Java DB to be based on an official, GA-ready release of Derby to be what Sun redistributes in Mustang. Otherwise databases created in Mustang will be locked in to Java DB. The problem is that it can't *actually* be GA until after JCP approves JSR 221, JDBC 4.0, which will happen in tandem with the GA release of the JDK, around 5 weeks after the JDK team needs their final integration bits from all the pieces going into it. I think what Rick is asking for is a release that is voted as GA-ready, has the GA-bit turned on, but because of JCP rules is not actually *made* generally available until JSR 220 becomes final. Since we all need to vet this release and approve it, it would be available to the Derby community, but not *generally* available by distributing it on all the Apache mirrors. I know this seems like a fine hair to split, but it's the only way we can be successful without Sun having to do a non-upgradable fork of Derby, which I don't think any of us want. I hope this helps to clear things up, even if it doesn't make things simpler :) David Daniel John Debrunner wrote: Rick Hillegas wrote: Daniel John Debrunner wrote: The mid-Sep Derby release candidate will be marked alpha or beta (JCP rules) so the databases won't upgrade anyway. I apologize for creating confusion here. We'd like Mustang to ship with a fully functional Derby, which creates upgradeable databases. So I'm assuming that we turn off the beta marker on the vetted candidate before handing the candidate to Mustang for QA bake-in. Sorry, I don't understand, I thought Derby 10.2 cannot be marked GA until Mustang ships. How can it be marked GA without violating the JCP requirements. Sorry if I'm being dense. Dan.
Re: Proposal for 10.2 release schedule
David Van Couvering wrote: ... In order for this to work, we need Java DB to be based on an official, GA-ready release of Derby to be what Sun redistributes in Mustang. Otherwise databases created in Mustang will be locked in to Java DB. The problem is that it can't *actually* be GA until after JCP approves JSR 221, JDBC 4.0, which will happen in tandem with the GA release of the JDK, around 5 weeks after the JDK team needs their final integration bits from all the pieces going into it. in other words, we have a classic catch-22. :-) I think what Rick is asking for is a release that is voted as GA-ready, has the GA-bit turned on, but because of JCP rules is not actually *made* generally available until JSR 220 becomes final. Since we all need to vet this release and approve it, it would be available to the Derby community, but not *generally* available by distributing it on all the Apache mirrors. It would still be easily available. And once downloaded, and probably redistributed further, downstream users would have no idea that they aren't working with an official Apache release. What is the specific legal verbiage we're working with here? -jean I know this seems like a fine hair to split, but it's the only way we can be successful without Sun having to do a non-upgradable fork of Derby, which I don't think any of us want. I hope this helps to clear things up, even if it doesn't make things simpler :) David
Re: Proposal for 10.2 release schedule
Jean T. Anderson wrote: David Van Couvering wrote: ... In order for this to work, we need Java DB to be based on an official, GA-ready release of Derby to be what Sun redistributes in Mustang. Otherwise databases created in Mustang will be locked in to Java DB. The problem is that it can't *actually* be GA until after JCP approves JSR 221, JDBC 4.0, which will happen in tandem with the GA release of the JDK, around 5 weeks after the JDK team needs their final integration bits from all the pieces going into it. in other words, we have a classic catch-22. :-) Are there any dates around JDBC 4.0/JSR221 that need to be factored in? I'm curious as to how we can vote on the release that's supporting JDBC 4.0 if the spec isn't final and/or generally available for people to read. Maybe we would be just voting on the current functionality of *Derby* and if it happens to match JDBC 4.0 that's a bonus. Dan.
Re: Proposal for 10.2 release schedule
Andrew McIntyre wrote: Call in the lawyers: From JSPA - 2.0.1 10 January 2005 [1], which presumably the ASF board has executed, being a JCP Member (they've even got quotes from Geir prominently featured on their about JCP 2.6 page [2]): 5.B. License to Create Independent Implementations. Dumb question, is Derby: - creating an independent implementation of JSR221 - or is it implementing a driver that adheres to JSR221? I would say Apache Harmony (when/if they tackle Jave SE 6) would be creating an independent implementation of JSR221 and that Derby is not. Dan.
Re: Proposal for 10.2 release schedule
Jean and Dan, you raise good points (a) what happens if someone downloads this GA-ready but not GA release of Derby. If for some reason we have to do a respin of the release (see (b)), how will they later know that it's not actually an official release of Apache? (b) is there a possibility, however, slight, that the JDBC spec could change after we have marked a release GA-ready I think these are great points for discussion. I get the sense that we all want to make this work, but are not sure how just yet. I have a suggestion, and I'm sure I'm missing something, but here goes. Is there a way we can vote on the release, and if it passes, Rick can flip the GA bit, sign it and put it on the shelf, but not make it available for download, even from the Derby site? This would allow us to re-spin if necessary (although I don't think it's likely) due to a last-minute change to JDBC, and would prevent a user from ending up with a release that looks and smells like it's an official Apache release but actually isn't. David Daniel John Debrunner wrote: Jean T. Anderson wrote: David Van Couvering wrote: ... In order for this to work, we need Java DB to be based on an official, GA-ready release of Derby to be what Sun redistributes in Mustang. Otherwise databases created in Mustang will be locked in to Java DB. The problem is that it can't *actually* be GA until after JCP approves JSR 221, JDBC 4.0, which will happen in tandem with the GA release of the JDK, around 5 weeks after the JDK team needs their final integration bits from all the pieces going into it. in other words, we have a classic catch-22. :-) Are there any dates around JDBC 4.0/JSR221 that need to be factored in? I'm curious as to how we can vote on the release that's supporting JDBC 4.0 if the spec isn't final and/or generally available for people to read. Maybe we would be just voting on the current functionality of *Derby* and if it happens to match JDBC 4.0 that's a bonus. Dan.
Re: Proposal for 10.2 release schedule
Andrew McIntyre wrote: Anyway, what's the trigger for breaching the contract here? If it's 'creation' alone, then rolling that release candidate surely qualifies as as creation. If it's 'creation and distribution,' well, is posting the release candidate in a public forum and on a public website (like one would have to do to vote on it) considered distribution in this case? I have no idea, because i'm not a lawyer. I don't either. I will try and get someone here to discuss this with the JCP lawyers and try and get some clarification about 'creation' vs. 'creation and distribution'. I can't see how you can be in trouble for creating a set of bits that nobody has access to, but IANAL. I guess you have somewhat answered my question from my other email: you must, even temporarily, make the official GA bits available for download, just so we can vote on the release. Could we remove the download once it's voted on, at least to keep the window of vulnerability to a minimum? I'm not saying that would satisfy the lawyers, but I'd like to know what is possible before we talk to them. How do we handle this normally, if you create a release candidate with the GA bit set, and then we reject the release. Don't we have the same problem already, with people getting access to a release that looks and smells like an official Apache release but actually isn't? Or maybe ask Geir, since he's VP of Java Community Process for the Apache Software Foundation, since similar instances may have come up fairly recently. [3] Even if we did ask Geir, he's not the last word on it. I'd rather hear it from the horse's mouth. I or someone else will get back to you. Thanks for all your input, and your research! andrew p.s. I'm assuming there's no TCK for JSR-221. P.S. I am pretty sure there is, but as I understand it, it just validates the interfaces are there. It's part of the overall TCK for Java SE 6, is my understanding. I am sure Lance will be happy to clarify. [1] http://www.jcp.org/aboutJava/communityprocess/JSPA2.pdf [2] http://jcp.org/aboutJava/communityprocess/announce/2004/JCP2.6.html [3] http://www.apache.org/foundation/records/minutes/2005/board_minutes_2005_12_21.txt (search for SUN ISSUES)
Re: Proposal for 10.2 release schedule
Daniel John Debrunner wrote: Andrew McIntyre wrote: Call in the lawyers: From JSPA - 2.0.1 10 January 2005 [1], which presumably the ASF board has executed, being a JCP Member (they've even got quotes from Geir prominently featured on their "about JCP 2.6 page" [2]): 5.B. License to Create Independent Implementations. Dumb question, is Derby: - creating an independent implementation of JSR221 - or is it implementing a driver that adheres to JSR221? I would say Apache Harmony (when/if they tackle Jave SE 6) would be creating an independent implementation of JSR221 and that Derby is not. You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final. The Derby Embedded and Network Client drivers provide implementations of the JDBC drivers based on JSR 221. A Java SE implementation provides the interfaces and concrete classes that are used by a JDBC driver for the given Java SE implementation. JSR 221 falls under the umbrella spec for Java SE 6. They all go final together. Dan.
Re: Proposal for 10.2 release schedule
that was MUCH clearer than what rick wrote.. thanks David Van Couvering wrote: Ok, this is very tricky. First, I'd like to make sure we're on the same page here about Java DB going into the JDK. I think in general the community thinks it's a good thing for Derby for Java DB to be in the JDK. It gives us great exposure and distribution. I also think the community would probably like it if databases created by the version of Java DB to be upgradable to a subsequent release of Derby, so that users can get the latest and greatest functionality of Derby directly from the Apache web site, or even upgrade to a future release of Cloudscape if they decide to get support from IBM. In order for this to work, we need Java DB to be based on an official, "GA-ready" release of Derby to be what Sun redistributes in Mustang. Otherwise databases created in Mustang will be "locked in" to Java DB. The problem is that it can't *actually* be GA until after JCP approves JSR 221, JDBC 4.0, which will happen in tandem with the GA release of the JDK, around 5 weeks after the JDK team needs their final integration bits from all the pieces going into it. I think what Rick is asking for is a release that is voted as "GA-ready", has the GA-bit turned on, but because of JCP rules is not actually *made* generally available until JSR 220 becomes final. Since we all need to vet this release and approve it, it would be available to the Derby community, but not *generally* available by distributing it on all the Apache mirrors. I know this seems like a fine hair to split, but it's the only way we can be successful without Sun having to do a non-upgradable fork of Derby, which I don't think any of us want. I hope this helps to clear things up, even if it doesn't make things simpler :) David Daniel John Debrunner wrote: Rick Hillegas wrote: Daniel John Debrunner wrote: The mid-Sep Derby release candidate will be marked alpha or beta (JCP rules) so the databases won't upgrade anyway. I apologize for creating confusion here. We'd like Mustang to ship with a fully functional Derby, which creates upgradeable databases. So I'm assuming that we turn off the beta marker on the vetted candidate before handing the candidate to Mustang for QA bake-in. Sorry, I don't understand, I thought Derby 10.2 cannot be marked GA until Mustang ships. How can it be marked GA without violating the JCP requirements. Sorry if I'm being dense. Dan. -- Rob Stephens Chief of Staff, Database Technology Group OPG Sun Microsystems, Inc. Bay Area, California US Phone 1-877-244-4740 or x51734 Mobile 1-510-928-2996 Fax 1-877-244-4740 Email [EMAIL PROTECTED]
Re: Proposal for 10.2 release schedule
David Van Couvering wrote: Andrew McIntyre wrote: Or maybe ask Geir, since he's VP of Java Community Process for the Apache Software Foundation, since similar instances may have come up fairly recently. [3] Even if we did ask Geir, he's not the last word on it. I'd rather hear it from the horse's mouth. I or someone else will get back to you. From the ASF point of view, which is what we are discussing here, I rather think Geir is the horse's mouth. It's the ASF's interpretation of the licence the ASF signed and the risks the ASF is willing to take that matter with a Apache Derby release. Dan.
Re: Proposal for 10.2 release schedule
Lance J. Andersen wrote: You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final. Are you *sure* you can't *have* a GA version, e.g the bits can't exist somewhere, as long as they're not officially declared generally available? If we can't even create the bits, then it is physically and logically impossible for us to give anything to the JDK team for integration. Personally, I think we need to get clarification from the JCP folks on this before we make any final conclusions about this. Thanks, David
Re: Proposal for 10.2 release schedule
OK, good point, thanks. David Daniel John Debrunner wrote: David Van Couvering wrote: Andrew McIntyre wrote: Or maybe ask Geir, since he's VP of Java Community Process for the Apache Software Foundation, since similar instances may have come up fairly recently. [3] Even if we did ask Geir, he's not the last word on it. I'd rather hear it from the horse's mouth. I or someone else will get back to you. From the ASF point of view, which is what we are discussing here, I rather think Geir is the horse's mouth. It's the ASF's interpretation of the licence the ASF signed and the risks the ASF is willing to take that matter with a Apache Derby release. Dan.
Re: Proposal for 10.2 release schedule
Hi, Lance. Sorry I had to challenge you publicly on the list, but I'm really worried that if we're not very careful we are going to paint ourselves into a corner and we are going to have to fork Derby in order to do a Java DB release. I think we need the JCP lawyers (and it sounds like the ASF lawyers) to weigh in on this question before we make any conclusions that could cause us real trouble. Thanks, David David Van Couvering wrote: Lance J. Andersen wrote: You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final. Are you *sure* you can't *have* a GA version, e.g the bits can't exist somewhere, as long as they're not officially declared generally available? If we can't even create the bits, then it is physically and logically impossible for us to give anything to the JDK team for integration. Personally, I think we need to get clarification from the JCP folks on this before we make any final conclusions about this. Thanks, David
Re: Proposal for 10.2 release schedule
That said, it's probably also good to hear from the JCP as well. It would probably help the ASF gauge what their exposure is and what approaches they feel comfortable with. David David Van Couvering wrote: OK, good point, thanks. David Daniel John Debrunner wrote: David Van Couvering wrote: Andrew McIntyre wrote: Or maybe ask Geir, since he's VP of Java Community Process for the Apache Software Foundation, since similar instances may have come up fairly recently. [3] Even if we did ask Geir, he's not the last word on it. I'd rather hear it from the horse's mouth. I or someone else will get back to you. From the ASF point of view, which is what we are discussing here, I rather think Geir is the horse's mouth. It's the ASF's interpretation of the licence the ASF signed and the risks the ASF is willing to take that matter with a Apache Derby release. Dan.
Re: Proposal for 10.2 release schedule
David Van Couvering wrote: Lance J. Andersen wrote: You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final. Are you *sure* you can't *have* a GA version, e.g the bits can't exist somewhere, as long as they're not officially declared generally available? If we can't even create the bits, then it is physically and logically impossible for us to give anything to the JDK team for integration. I think we are talking different things here as you are talking about getting your final version of your product ready to be released based on a JSR which is getting ready to go final , which is fine, which is different from what i was trying to say. http://jcp.org/en/resources/guide#fab gives you an overview of how a JSR goes final. Personally, I think we need to get clarification from the JCP folks on this before we make any final conclusions about this. Thanks, David
Re: Proposal for 10.2 release schedule
Hi,Jean commented on David's post:... In order for this to work, we need Java DB to be based on an official,"GA-ready" release of Derby to be what Sun redistributes in Mustang.Otherwise databases created in Mustang will be "locked in" to Java DB.The problem is that it can't *actually* be GA until after JCP approvesJSR 221, JDBC 4.0, which will happen in tandem with the GA release ofthe JDK, around 5 weeks after the JDK team needs their final integrationbits from all the pieces going into it. in other words, we have a classic catch-22. :-)No, not at all. What happens right now is that we publish a release candidate that is available for the Derby community to test and vote on. Once the vote is complete, the release manager ties up some of the loose ends (records the vote results, pushes the bits around) and publishes the release on the Apache mirrors. Subsequently, other loose ends are tied (official announcement on Apache general email alias).What Rick is proposing to happen is for the community to vote and subsequently tie up some loose ends (record the vote results, send the bits to the Mustang folks instead of to the Apache mirrors). Once the Mustang release is official, continue tying up loose ends (publish the release on the Apache mirrors). And more loose ends (official announcement on Apache general email alias). So the only thing that changes compared to today is the delay that Rick mentioned between community approval of the bits and posting the bits to the Apache mirrors. I think what Rick is asking for is a release that is voted as"GA-ready", has the GA-bit turned on, but because of JCP rules is notactually *made* generally available until JSR 220 becomes final. Sincewe all need to vet this release and approve it, it would be available tothe Derby community, but not *generally* available by distributing it onall the Apache mirrors. It would still be easily available. And once downloaded, and probablyredistributed further, downstream users would have no idea that theyaren't working with an official Apache release.As I understand it, this is what happens today. Once the release candidate is announced, anyone can theoretically grab the bits and distribute them before the release is voted on and available from the mirrors. Is this considered a problem today?What is the specific legal verbiage we're working with here?IANAL, but the only license available right now (the license under which the community is using the bits) is an evaluation license for JSR 221, which reads, in part:Subject to the terms and conditions of this license, Sun hereby grants you a fully-paid, non-exclusive, non-transferable, limited license (without the right to sublicense) under Sun's intellectual property rights to review the Specification only for the purposes of evaluation.Until Mustang goes GA, there is no redistribution license available.Craig -jean I know this seems like a fine hair to split, but it's the only way wecan be successful without Sun having to do a non-upgradable fork ofDerby, which I don't think any of us want.I hope this helps to clear things up, even if it doesn't make thingssimpler :)David Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
