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
