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 19:34:30 GMT
I've updated the Wiki page to reflect some of this discussion and my 
sense of where things are ending up.  You can use the diff mechanism of 
the Wiki to see what's changed.

David

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.
> 
> 
> 

Mime
View raw message