commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodrigo di Lorenzo Lopes <bren...@terra.com.br>
Subject Re: [math] 1.1 clirr report, backward compatibility
Date Sun, 12 Jun 2005 21:17:42 GMT
Hi,

No, I dont see problems in freeze interface, with an exception:
_ Java (Commons Math)  is not a friendly with linear algebra. We are 
using vectors like one row (or column) matrix (it is a real pain to use 
vectors this way), and it is not uncommon multiplies arrays by Euclidean 
vectors. Moreover vectors  are  not only Euclidean  Spaces (in fact, 
matrixes are generalization of Vectors)  So, to reduce the contact 
surface and to treat most abstrac concepts, I´d like that Matrix 
interface inherences from a Vector interface. And using more abstract 
interface could be easier to freeze a interface.

[]´s
Rodrigo

Mark Diggory 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
>
>


---------------------------------------------------------------------
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