commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [math] 1.1 clirr report, backward compatibility
Date Sun, 12 Jun 2005 17:00:53 GMT
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


Mime
View raw message