Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of mdiggory@gmail.com designates
 64.233.184.200 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=EsDePyTJ1H/FvsK967RuGi/WyZn26Qv6KUjiqCqxlLjFuWV8UqynyDn+rNFbVOqLNjeDf+zo+KvcCB+ZWBPDD2xIR8F470XbGzfhrq0QFm8ec7e/La91W5BE8ls4bn6sQsIKReuOiFn4+kcegm+aPJik+mlBTT+xGvMBEP8ZGhY=
Message-ID: <42AC6F02.7050201@gmail.com>
Date: Sun, 12 Jun 2005 13:21:06 -0400
From: Mark Diggory <mdiggory@gmail.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [math] 1.1 clirr report, backward compatibility
References: <8a81b4af05061208137d6b5650@mail.gmail.com>
	 <42AC6013.2010101@apache.org> <8a81b4af05061210006b69e1b2@mail.gmail.com>
In-Reply-To: <8a81b4af05061210006b69e1b2@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sure this sounds fine for the current case.

Yet another idea. I notice that sometimes API's will use an abstract 
"Adapter" strategy where those publishing a "standard" interface will 
also provide an "Adapter" or default implementation with a stubbed out 
implementation. Such an Adapter or "Stub" acts as a SPI for any third 
parties implementing the API.

The power of this is that you can add methods into the Interface in 
minor versions and implement "stubs" for them, then third party 
implementations are still backwards/forwards compatible because they 
inherit the stub. It is then the third parties job to move their 
implementation forward by implementing the stubs.

For instance in our implementation of BigMatrix/Matrix, we would direct 
the third parties not to implement these interfaces directly, but to 
override the stub we provide as a backed SPI to the API.

Either way, have a good flight and we'll chat again later...
-Mark

Phil Steitz wrote:

>About to get on a plane, so may not be able to respond to follow ups
>for a day or two, but my plan was to leave the methods in the
>implementations, but remove from the interfaces (so the methods would
>be there to use, you would just have to cast or use the impls
>directly.  I think it is best to stick with the more or less standard
>practice in commons and keep 1.x all binary compatible, with only 2.0
>allowed to break anything.  Even if we made the interface final, the
>problem would be breaking those who *implemented* the interface
>without the new methods.  I will think about this some more and am
>open to any other creative suggestions that anyone has on how to
>handle this.
>
>Phil
>
>On 6/12/05, Mark Diggory <mdiggory@gmail.com> wrote:
>  
>
>>Very cool Phil,
>>
>>So, when (which version) would we make this methods available? I'm
>>concerned that this report suggests that adding methods to an interface
>>is breaking backward compatibility. When I think the opposite, in that
>>its breaking "forwards compatibility" of existing application. You tend
>>to need to break forwards compatibility to make progress on an API's
>>design.
>>
>>In out case, adding these methods should only effect a small subset of
>>the user base (specifically those who may have extended either the
>>interface or the implementation on their own, effecting them because the
>>signatures may be incompatible). I'm not even sure if we have anyone in
>>our userbase actually doing this...
>>
>>Stray Thoughts:
>>
>>1.) Should versioning drive development or vis versa (maybe we're
>>already working on 2.0 if we're breaking compatibility with 1.0)?
>>
>>2.) I've been dealing with versioning on another project lately, we
>>adopted the following standard versioning scheme
>>
>>xx.yy.zz
>>
>>where
>>
>>xx: Major version number incremented when major backward incompatible
>>changes occur.
>>yy: Minor version number incremented when forwards incompatible changes
>>occur
>>zz: Patch version number, incremented when changes neither cause
>>forwards or backwards incompatibility,
>>
>>3.) Maybe we should consider making the Interfaces "final"? This would
>>stop users from extending them and allow us more room to make
>>additions/removals to the interfaces without the above usecase I
>>initially referred to occurring above...
>>
>>-Mark
>>
>>Phil Steitz wrote:
>>
>>    
>>
>>>A clirr report comparing 1.0 and 1.1-dev is available here:
>>>
>>>http://people.apache.org/~psteitz/math-1.1-clirr.txt
>>>
>>>The ERRORs shown are due to the addition of the submatrix methods to
>>>the RealMatrix and BigMatrix interfaces.  I would like to remove the
>>>interface changes (leaving the new methods in the impls) to preserve
>>>compatibility.  Any objections to this?  Any other problems?
>>>
>>>Phil
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>      
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>    
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org