db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: making Derby secure by default
Date Fri, 16 Sep 2011 12:59:52 GMT
I want to make sure that we are not talking past one another. Back in 
2006 we talked about stability and backward compatibility. David Van 
Couvering wrote a proposal which he didn't bring to a vote: 
http://wiki.apache.org/db-derby/ForwardCompatibility . In that proposal, 
backward incompatibilities would be allowed when we bumped the major 
release id (e.g., the change from 10.* to 11.*). More exactly, a 
backward incompatibility would be what drove us to change the major 
release id. It would be what drove us to call a release 11.0 rather than 

I believe the benefits of a secure-by-default product are important 
enough to justify a backwardly incompatible release and therefore to 
bump the major release id from 10 to 11. I believe that Derby's current 
security story is unsustainable.

If the whole community can't move to a secure-by-default product, I am 
worried that Derby development may fork. Those of us who are interested 
in a secure-by-default configuration will put our effort behind that 
profile and those who are interested in the old configuration will focus 
on the current profile. It may be possible to limit the fork to personal 
environments and automated tests, but I confess, I don't understand how 
this would play out. Before launching into that discussion, I would like 
to ask if the community could support a secure-by-default 11.0 trunk 
sometime after 10.9 in the interests of avoiding a development fork.


View raw message