db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
Date Fri, 31 Mar 2006 18:45:42 GMT
I also wanted to respond to the suggestion that compatibility be 
guaranteed for a given time period, versus tying it to release levels.

If we don't *require* that major releases be incompatible, but simply 
say this is the only time you *can* do it, then I don't see what the 
issue is.  We can do as many major releases as we want in five years.

If we want to also provide a guarantee that any feature will not be 
broken for five years, that's OK, but I think it would be odd to break 
compatibility in a minor release just because it's been five years...

Or am I not fully understanding your proposal, Kathey?


Kathey Marsden wrote:
> Rick Hillegas wrote:
>>I think you may have already addressed the following issues in email,
>>but I don't see the results rolled onto the wiki page. Please pardon
>>my nitpicking. This kind of discussion turns me into a tiresome,
>>pedantic Mr. Hyde:
>>1) The cardinal rule. I recommend wordsmithing the cardinal rule: "The
>>goal is to allow any application written against the public interfaces
>>an older version of Derby can run, without any changes, against a
>>newer version of Derby." To me the following formulation reads better
>>"This is our goal: An application which ran against Derby yesterday
>>will run against a higher version of Derby tomorrow."
> I prefer the original wording with only a small grammatical change to
> instead of can.
> "The goal is to allow any application written against the public
> interfaces an older version of Derby to run, without any changes,
> against a newer version of Derby."
> It is good to think past tomorrow.
>>But is that really the cardinal rule? Maybe we really mean this: "This
>>is our goal: An application which runs against a Derby release today
>>will also run tomorrow against the next minor release. 
> I  do not like this wording .    It might seem to imply that you cannot
> skip minor releases e.g. go from 10.l  to 10.3.
> It might also seem to imply that you cannot  run a 10.1 client with a
> 10.3 server for example.  
>>We strive to minimize churn for applications migrating to the next
>>major release of Derby. However these migrations may entail
>>application changes."
> The way  major releases are described in this mail is the way I have
> seen them  in the past,  where we break upgrade,  client/server
> compatibility and many other things  and it is like switching to a new
> product, but I want better for the users of  Derby 10 when they switch
> to 11.
> I still need to think a lot about the whole major version boundary
> thing.  It seems like we like solaris will be set at the same major
> version for a very long time.   As I stated before I think for some
> things a time based approach seems most appropriate. You can expect your
> client to work with new servers for the next five years for example. We
> should  not just leave users trying to figure out how to upgrade  their
> server and all of their clients all in one night because we  bumped from
> 10 to 11.
> If we expect upgrade=true to work from 10 to 11 we should expect
> client/server compatibility to be maintained as well.
> So either the time based approach or for major versions  have
> compatibility with the previous and next  major versions.    For example
> with Derby 11 you can use Derby 10 or Derby 12, but not Derby 13.
>>2b) Our DRDA implementation may incorrectly transport datatypes not
>>recognized by DRDA. Conforming to the DRDA spec may mean removing this
>>transport capability and breaking applications which select the
>>unsupported datatypes.
> Protocol has an impact on client JDBC, SQL  and even the ability to
> connect and those cannot be broken.
> Client and server can have version dependent behaviour to mitigate the
> change to DRDA compliant behavior.
>>3) Client/server compatibility.
>>I would expect to find these rules spelled out on the wiki page. 
> Yes I agree these should be spelled out because obviously different
> readers can deduce different things.

View raw message