Re: [math] Smaller Packages / Artifacts / Dependencies

2015-11-07 Thread Gilles
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 commons-mat

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

2015-11-07 Thread Thomas Neidhart
On 11/07/2015 04:25 AM, Bernd Eckenfels wrote: > Hello, > > I tried to raise that concern in the message already, but it is probably > worth repeating it explicitly: this is not a real bug > in the Commons-Collection class, and it might not be worse fixing it, as > there are possibly tons of other

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

2015-11-07 Thread Mark Thomas
On 07/11/2015 10:13, Thomas Neidhart wrote: > On 11/07/2015 04:25 AM, Bernd Eckenfels wrote: >> Hello, >> >> I tried to raise that concern in the message already, but it is probably >> worth repeating it explicitly: this is not a real bug >> in the Commons-Collection class, and it might not be wors

Re: [math] Version mgt idea

2015-11-07 Thread Emmanuel Bourg
A roughly equivalent alternative would be to release beta artifacts until the API stabilizes and use a different base package and different Maven coordinates for each iteration. For example, commons-math 4.0-beta1 is released with the org.apache.commons:commons-math4-beta1 coordinates and the clas

Re: [math] Smaller Packages / Artifacts / Dependencies

2015-11-07 Thread Emmanuel Bourg
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 ---

Re: [math] Version mgt idea

2015-11-07 Thread James Carman
On Fri, Nov 6, 2015 at 11:17 AM Phil Steitz wrote: > Here is an idea that might break our deadlock re backward > compatibility, versioning and RERO: > > Agree that odd numbered versions have stable APIs - basically adhere > to Commons rules - no breaks within 3.0, 3.1, ..., 3.x... or 5.0, > 5.1..

Re: [math] Version mgt idea

2015-11-07 Thread Gilles
On Sat, 7 Nov 2015 16:52:21 +0100, Emmanuel Bourg wrote: A roughly equivalent alternative would be to release beta artifacts until the API stabilizes and use a different base package and different Maven coordinates for each iteration. For example, commons-math 4.0-beta1 is released with the or

Re: [math] Smaller Packages / Artifacts / Dependencies

2015-11-07 Thread 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 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 ind

Re: [math] Smaller Packages / Artifacts / Dependencies

2015-11-07 Thread Pascal Schumacher
I guess searching github is more representative: https://github.com/search?q=org.apache.commons.math3&type=Code&utf8=%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 separ

Re: [math] Version mgt idea

2015-11-07 Thread Phil Steitz
On 11/7/15 10:29 AM, Gilles wrote: > On Sat, 7 Nov 2015 16:52:21 +0100, Emmanuel Bourg wrote: >> A roughly equivalent alternative would be to release beta artifacts >> until the API stabilizes and use a different base package and >> different >> Maven coordinates for each iteration. >> >> For examp

Re: [math] Version mgt idea

2015-11-07 Thread James Carman
As long as the maven coordinates follow suit, go for it. The community will let us know if it is a pain in the ass. Also, no need to worry about even/odd with this approach On Sat, Nov 7, 2015 at 12:29 PM Gilles wrote: > On Sat, 7 Nov 2015 16:52:21 +0100, Emmanuel Bourg wrote: > > A roughly equi

Re: [math] Version mgt idea

2015-11-07 Thread Phil Steitz
On 11/7/15 12:58 PM, James Carman wrote: > As long as the maven coordinates follow suit, go for it. The community will > let us know if it is a pain in the ass. Also, no need to worry about > even/odd with this approach I think its better to use the even/odd approach with this package naming trick

Re: [math] Version mgt idea

2015-11-07 Thread Phil Steitz
On 11/7/15 2:15 PM, Phil Steitz wrote: > On 11/7/15 12:58 PM, James Carman wrote: >> As long as the maven coordinates follow suit, go for it. The community will >> let us know if it is a pain in the ass. Also, no need to worry about >> even/odd with this approach > I think its better to use the eve

Re: [math] Version mgt idea

2015-11-07 Thread sebb
So is the idea to change both the Maven artifact ID and package name for the beta releases? i.e. the stable releases would use Maven AID: commons-math4 package: org.apache.commons.math4 and beta releases: Maven AID: commons-math4-beta{n} package: org.apache.commons.math4.beta{n} Have I got thi

Re: [collection][security] InvokerTransformer missused in java object

2015-11-07 Thread Gabriel Lawrence
Howdy, Thought I'd dive in here. Sorry that things got pointed in your direction on this. That was out of our control. Chris and I had a bunch of conversations about if we thought this was worth reporting to you when we discovered it. Perhaps we made the wrong decision, hard to say. We don't think

Re: [lang] Outdated Information on Jira Summary Page

2015-11-07 Thread Pascal Schumacher
Thanks. :) Am 06.11.2015 um 11:46 schrieb Benedikt Ritter: Hello Pascal, 2015-11-05 20:25 GMT+01:00 Pascal Schumacher : Hello everybody, https://issues.apache.org/jira/browse/LANG/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel shows: RELEASE PLAN Lang 2.x - There are no