Hi Kathey,
Thanks for the quick response. Some comments inline...
On 4/11/12 9:29 AM, Katherine Marsden wrote:
On 4/11/2012 9:16 AM, Rick Hillegas wrote:
I am volunteering to manage a 10.9.1 feature release. Please let me
know if you are comfortable with the plan posted here:
http://wiki.apache.org/db-derby/DerbyTenNineOneRelease The plan calls
for a first release candidate on May 21 and GA on June 20.
Since the number of upgrade/downgrade trajectories and mixed client
server versions increases dramatically with each new version, along
with more builds and tests with multiple jdk versions and platforms
to track. I would think maybe a bug fix drive followed by a 10.8.3
release and then a 10.9 late in the year with more than the short list
of features we have on the 10.9 list would be good.
Can you give us more detail about what makes this testing burden
increase dramatically with each new release? At first blush, it seems to
me that the burden should increase linearly and therefore the expense
should be hidden by the more than linear increase in machine power over
time. Maybe there is some tooling we could build or simplification we
could investigate which would reduce this increase to a linear problem.
Are there pressing needs that necessitate a 10.9 vs a 10.8.3 right away?
I would like to get NATIVE authentication into users' hands. I'd also
like to see the remaining bits of JDBC 4.1 go GA.
I believe release early, release often is good, but because of the
explosive nature of maintenance with each new major release, I think
it might be good to do one more 10.8 release before 10.9.
Another 10.8 release sounds like a good idea for people who want
targetted bug fixes on a stable codebase. I have no objection to someone
else producing a 10.8.3 release.
Thanks,
-Rick
Just my opinion.
Kathey
