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
