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