db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Satheesh Bandaram" <banda...@gmail.com>
Subject Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
Date Sat, 01 Apr 2006 18:30:23 GMT
This is a very good list... Thanks for putting this together. Should we
consider documenting some of the important items once the Wiki page is more
firmed up?

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 <David.Vancouvering@sun.com> 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.
> >
> >
> >
>

Mime
View raw message