So, tonight at the Derby BoF at ApacheCon I suggested to the other people in attendance that it might be advisable for Derby to have a 10.1.4 release, and quickly.[1] This is for two reasons:
1 - There is a hard deadline of November 1, 2006 to make the changes detailed at http://www.apache.org/legal/src-headers.html to the source files for a release. While these changes have mostly[2] been made to 10.2 to bring all of our files into compliance, these changes have not been made to the 10.1 branch. 2 - Several important bugfixes have recently been merged into the 10.1 branch, the most important of which I think is DERBY-1854, where a table containing a foreign key can become corrupted if one compresses the table. But there are other good reasons[3] as well. So, Derby 10.1.3.1 was released, a batch of regressions was reported by users, and fixes were proposed, committed, and merged relatively quickly (yay! good for us). It has been several weeks since a report of a new serious regression has come in and all the fixes for the ones that were reported are in and already merged to the 10.1 branch. So, we've got important regressions in 10.1 that have been identified and already fixed in the 10.1 branch. But, if that hard deadline of November 1, 2006 passes, there's a whole lot of *extra* work that would have to be done to have another 10.1 release. So, if we can get a release out by Oct. 31, then we've prevented extra work for the community while putting important fixes for real regressions into the hands of real users. Double plus good all the way around, I think. So whoever picks this up gets an easy one: all the bugs we want in the release are already fixed! There is almost no "herding of cats" to be done. All you have to do is shuffle around a couple of JIRAs that aren't really that important that are currently assigned Fix In 10.1.3.2 or 10.1.4.0, and then get consensus on a release candidate in just under three weeks. Also, I'm not planning on volunteering for this release. What I'm hoping to see here is two-fold: that the Derby community can be a little more agile with its release processes[4], and I also think it would be good for other committers besides myself (and Rick and Kathey) to understand the process. Any takers? andrew [1] Q asked at the BoF: why even bother with 10.1 since 10.2 was just released? A: a) minimal delta on a stable branch means minimal concern upgrading. 10.1.1 -> 10.1.2 -> 10.1.3 was (hopefully) smooth, so 10.1.3 -> 10.1.4 should be just as smooth: just replace the new derby jars with the old ones. All of our documented compatibility goals that are community enforced aim for this goal, even if they are not always met 100% (since regressions can, and do, happen). And b) inertia on the user's part. Upgrading to 10.2 really is an upgrade. There are lots of considerations to be made, release notes to read and understand, the database file format itself has to be upgraded, maybe I want to wait for official binaries with JDBC 4 support in them, maybe it's the first release on the 10.2 line so I want to wait and see what issues early adopters flush out, etc., etc. So there is value to an end user of 10.1.3.x to have the regressions found there fixed, released, and documented in a 10.1.4.x release. [2] Remaining for this compliance task for trunk and 10.2 are the *.sql test files, which needs the Apache header inserted as SQL comments at the beginning, and associated output files. I have ideas for making these changes to the source and master files in an automated fashion. I don't believe that additional sed'ing of the scripts is desirable. [3] http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10594&fixfor=12311972&sorter/field=issuekey&sorter/order=DESC [4] "Projects still do releases? I thought you just grabbed the latest snapshot using maven..." wow, tough crowd. *tap, tap* is this thing on?
