On 11/07/2015 04:00 AM, Gilles wrote:
On Fri, 6 Nov 2015 15:06:35 -0600, Ole Ersoy wrote:
If math is broken up into smaller artifacts it will make it easier
for users to upgrade, even if it it breaks compatibility, as well as
speed up the release frequency. So for example:
On Fri, 6 Nov 2015 15:06:35 -0600, Ole Ersoy wrote:
If math is broken up into smaller artifacts it will make it easier
for users to upgrade, even if it it breaks compatibility, as well as
speed up the release frequency. So for example:
commons-math-optimization (Or even more granular
Le 07/11/2015 11:00, Gilles a écrit :
> [At some point, releasing separate JARs could also provide us with
> indirect feedback on which parts of CM are actually used.]
You might find this interesting:
https://codesearch.debian.net/perpackage-results/import
org.apache.commons.math
Emmanuel
I guess searching github is more representative:
https://github.com/search?q=org.apache.commons.math3=Code=%E2%9C%93
Am 07.11.2015 um 18:43 schrieb Gilles:
On Sat, 7 Nov 2015 16:56:45 +0100, Emmanuel Bourg wrote:
Le 07/11/2015 11:00, Gilles a écrit :
[At some point, releasing separate JARs
On Sat, 7 Nov 2015 16:56:45 +0100, Emmanuel Bourg wrote:
Le 07/11/2015 11:00, Gilles a écrit :
[At some point, releasing separate JARs could also provide us with
indirect feedback on which parts of CM are actually used.]
You might find this interesting:
Thanks for the link. Interesting
If math is broken up into smaller artifacts it will make it easier for users to
upgrade, even if it it breaks compatibility, as well as speed up the release
frequency. So for example:
commons-math-optimization (Or even more granular commons-math-optimization-lp,
commons-math-optimization-ga,
