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
10.10.
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.
Thanks,
-Rick
