commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Diggory <mdigg...@gmail.com>
Subject Re: [math] 1.1 clirr report, backward compatibility
Date Sun, 12 Jun 2005 16:17:23 GMT
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


Mime
View raw message