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:20:18 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