db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <sathe...@Sourcery.Org>
Subject Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
Date Sat, 01 Apr 2006 06:50:41 GMT


David W. Van Couvering wrote:

>
> 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?
>
I think Kathey probably meant compatibility should be maintained for a
specific amount of time AND can only be broken in a major release.

Satheesh

> 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