I was *this* close to doing a vote for this. Maybe it's time to make
this happen?
David
[EMAIL PROTECTED] wrote:
"Bernt M. Johnsen" <[EMAIL PROTECTED]> writes:
So, the question is then: Is this a Derby 10 release, or should it
really be Derby 11?
Myself, I have no strong feelings, but wanted to raise the discussion.
Me neither, but here are my observations:
1) Derby's charter doesn't mention backward compatibility (or forward
compatibility) at all
2) It has been argued that backward compatibility is implied by the
"easy to use" requirement, but I think this discussion shows this
to be inadequate. Clearly, both "secure by default" and "backward
comatibility" could be seen as ease of use features (The charter
only says "Secure". It doesn't mention "secure by default"). But
which ease of use feature is more important? I think the implicit
"backward compatibility" requirement and its importance relative to
other requirements should be added to the charter.
3) As far as I can tell (from the Derby website), the idea that an
incompatibility is OK iff you bump the major version number has not
been formally accepted/ratified by the Derby community. David van
Couvering has written a Wiki page about this,
http://wiki.apache.org/db-derby/ForwardCompatibility#head-fb84926793e6687822e8397203265a6497911efe
which (in my interpretation) suggests that requiring the -unsecure
option is an INCOMPATIBLE change to a STABLE interface, and that
this should only be allowed when changing the major version
number. However, this wiki page has numerous disclaimers which
state that this is "just a draft" and "work in progress".
If there has been a vote on this, it is not recorded on
http://wiki.apache.org/db-derby/VoteResults
According to nabble the last discussion about this seems
to be
http://www.nabble.com/-PRE-VOTE-DISCUSSION--Compatibility-rules-and-interface-table-tf1782536.html#a4854300
which doesn't seem to reach a consensus. There doesn't seem to be
any major disagreement though...
