Daniel John Debrunner wrote: >In my view all public interfaces must remain compatible. > >I believe these are the public interfaces, are there any others? > > [snip public api list]
>- External behaviour defined by jar file manifest entries, e.g. OSGi >bundling now and auto-loading of JDBC driver in the future. > > > Would sticky issues like ability to mix jar versions, maintaining existing jar file names, conforming to exisiting documented security permissions for existing behaviour and ensuring jar file growth is commesurate with functionality improvement fall into this category? Also, there are gray areas . - Changes to things like error codes, sqlstates and system tables. - Changes to make client match embedded for implementation defined behaviour. I think here common sense and sensitivity to users has to guide us as to when a change is acceptable or a lot of advance notification to the user community is needed. Changing SQLStates from null to something useful probably does not need much advance notification to the user community, just documentation is sufficient. Changing the error codes to match embedded probably requires significant prior notification. I think the 10.1 tests are a good way to try to understand the impact changes might have on existing applications. I've started to think maybe instead of strictly checking for behaviour depending on server version we should just change them all to work with 10.1, 10.2 and future versions like we ask our users to do with their applications. If nothing else, it would make for good sensitivity training. >If this seems like a good list I'll create a wiki page. > > > Thanks Dan!
