db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: VOTE: Principles of sharing code
Date Wed, 26 Oct 2005 01:03:31 GMT
Knut Anders Hatlen wrote:

> Daniel John Debrunner <djd@debrunners.com> writes:
>>David W. Van Couvering wrote:
>>>Daniel John Debrunner wrote:
>>>>David W. Van Couvering wrote:
>>>>Is this a requirement, 'will need', since the wiki page says "We should
>>>>strive for forward compatibility between major releases, ..." and
>>>>elsewhere in referring to incompatibility between major releases it says
>>>>"(and this is to be avoided)"?
>>>Perhaps I misunderstood, but I thought Kathey felt that if we did not
>>>*guarantee* compatibility then it would be simpler and more correct to
>>>say that a user should expect and plan for incompatibility between major
>>>releases, rather than hope and pray for compatibility.
>>>I would prefer to word it something like "may need" instead of "will
>>>need" but I was concerned about pushback from Kathey :)
>>Do you have a link to Kathey's e-mail, I looked in the archives (boy do
>>I hate the new gui) but couldn't see what you are referring to?
> For discussions of this size only Google can help you...
> I think this was the article:
> http://www.nabble.com/Re%3A-VOTE%3A-Shared-Components-Guidelines-p1187186.html

Assuming that is what David was referring to, I see this quote:

> Kathey said ...
> That's just a stab at it, but I think it has most of the parts that are
> really controversial, covers the significant risk areas, and makes it
> clear that users can no longer mix jars across major versions.   I think
> it is good to be clear about that since as I see it, that is currently
> the only proposed change to external behaviour.  The Wiki page says that
> developers should try to avoid breaking compatiblity across major
> versions and that's fine,  but  makes no committment, so it is best if
> we just document  that it won't work.

I disagree that we take the approach that since we can't guarantee
compatibility then we document that it won't work. To follow that
thought to the extreme, that would mean that if a bump in major version
means some incompatible application api, then we should document that
applications will not work between major versions.

I much prefer the approach in the wiki page, strive for compatibility.
If such a requirement comes up for a specific release, then we can
document that sharing jars between 12.x and 13.x is not supported.


View raw message