Some more items to include:
1) Trace outputs. Many modules have tracing support. Should this be marked PRIVATE?
2) Errorlog contents. UNSTABLE?
3) Query plan output as displayed by RUNTIMESTATISTICS. UNSTABLE?
4) Derby properties. I think Documented properties should be marked STABLE. Undocumented properties are UNSTABLE.
Satheesh
On 3/31/06, David W. Van Couvering <[EMAIL PROTECTED]> wrote:
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.
>
>
>
