10.1.4, anyone?

[Andrew McIntyre <mc...@gmail.com>]

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?