Re: [math] Version mgt idea

[Gilles]

On Fri, 6 Nov 2015 17:02:01 -0700, Phil Steitz wrote:

On 11/6/15 4:46 PM, Gary Gregory wrote:
On Fri, Nov 6, 2015 at 3:01 PM, Phil Steitz  
wrote:



On 11/6/15 2:51 PM, Gary Gregory wrote:

On Fri, 6 Nov 2015 09:17:18 -0700, 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... but even-numbered lines can include breaks -


...

This sounds awfully complicated for my puny human brain.
How, exactly?  Seems pretty simple to me.  The even-numbered 
release

lines may have compat breaks; but the odd-numbered do not.
It's bad enough that I have to remember how each FOSS project 
treats
versions numbers, but having an exception within a Commons 
component is

even worse. This is a non-starter for me.

Do you have any better suggestions?  The problem we are trying to
solve is we can't RERO while sticking to the normal compat rules
without turning major versions all the time, which forces users to
repackage all the time and us to support more versions concurrently
than we have bandwidth to do.


I do not see how a different version scheme will determine how many
branches the community supports.


If we just keep one 4.x branch that keeps cutting (possibly
incompatible) releases, that is just one line, one branch.  If we
have to cut 4.1, 4.2, 4.3 as 4, 5, 6 instead and we don't allow any
compat breaks, we end up having to maintain and release 4.0.1,
5.0.1, 6.0.1 instead of just 4.3.1, for example, or we just strand
the 4, 5 users in terms of bug fixes as we move on to 6.


Breaking BC without a package and coord change is a no-go.


We have done this before and we will probably do it again - and more
if we have to don't separate out an unstable line.

 You have to
think about this jar as a dependency that can be deeply nested in a
software stack. Commons components are such creatures. I 
unfortunately run
into this more than I'd like: Big FOSS project A depends on B which 
depends
on C. Then I want to integrate with Project X which depends on Y 
which
depends on different versions of B and C. Welcome to jar hell if B 
and C

are not compatible. If B and C follow the rule of break-BC -> new
package/coords, then all is well.


The mitigation here is that we would not expect the even-numbered
releases to be deployed widely.


Or we can prevent any potential JAR hell by changing the top-level
package name for every release in the unstable series:

4.0 -> org.apache.commons.math4u0
4.1 -> org.apache.commons.math4u1

This would also offer the possibility to write a code using
classes from several unstable releases (e.g. to compare their
performance).

Gilles


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Version mgt idea

[Gilles]

On Fri, 6 Nov 2015 16:53:00 -0800, Gary Gregory wrote:
On Fri, Nov 6, 2015 at 4:42 PM, Gilles  
wrote:



On Fri, 6 Nov 2015 17:02:01 -0700, Phil Steitz wrote:


On 11/6/15 4:46 PM, Gary Gregory wrote:

On Fri, Nov 6, 2015 at 3:01 PM, Phil Steitz 


wrote:

On 11/6/15 2:51 PM, Gary Gregory wrote:



On Fri, 6 Nov 2015 09:17:18 -0700, 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... but even-numbered lines can include breaks -

...



This sounds awfully complicated for my puny human brain.


How, exactly?  Seems pretty simple to me.  The even-numbered 
release

lines may have compat breaks; but the odd-numbered do not.

It's bad enough that I have to remember how each FOSS project 
treats
versions numbers, but having an exception within a Commons 
component is

even worse. This is a non-starter for me.


Do you have any better suggestions?  The problem we are trying to
solve is we can't RERO while sticking to the normal compat rules
without turning major versions all the time, which forces users 
to
repackage all the time and us to support more versions 
concurrently

than we have bandwidth to do.

I do not see how a different version scheme will determine how 
many

branches the community supports.



If we just keep one 4.x branch that keeps cutting (possibly
incompatible) releases, that is just one line, one branch.  If we
have to cut 4.1, 4.2, 4.3 as 4, 5, 6 instead and we don't allow any
compat breaks, we end up having to maintain and release 4.0.1,
5.0.1, 6.0.1 instead of just 4.3.1, for example, or we just strand
the 4, 5 users in terms of bug fixes as we move on to 6.



Breaking BC without a package and coord change is a no-go.



We have done this before and we will probably do it again - and 
more

if we have to don't separate out an unstable line.


 You have to
think about this jar as a dependency that can be deeply nested in 
a
software stack. Commons components are such creatures. I 
unfortunately

run
into this more than I'd like: Big FOSS project A depends on B 
which

depends
on C. Then I want to integrate with Project X which depends on Y 
which
depends on different versions of B and C. Welcome to jar hell if B 
and C

are not compatible. If B and C follow the rule of break-BC -> new
package/coords, then all is well.



The mitigation here is that we would not expect the even-numbered
releases to be deployed widely.



Or we can prevent any potential JAR hell by changing the top-level
package name for every release in the unstable series:

4.0 -> org.apache.commons.math4u0
4.1 -> org.apache.commons.math4u1

This would also offer the possibility to write a code using
classes from several unstable releases (e.g. to compare their
performance).



Pardon my daftness, but if you change package/coord names, what are 
you

gaining compared to the usual major version changes?



Objectively, nothing...
But IIUC Phil's paragraph, above, using a dual numbering would
highlight the "unstable" nature of some releases: the whole 4.x
series would be known (in advance) to be unstable, while if we
release a usual 4.0, some user might assume it to be "stable",
only to see it abandoned a few months later when 5.0 is released.
Moreover, at each major number bump, we'd have to advertize (in
words) whether that release is stable or not, while with the dual
numbering the warning would be carried by number in the package
name.

Maybe it's only a psychological trick.  But if it can help to
release more often, it would have led to a real improvement! :)

Gilles



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Version mgt idea

[Gary Gregory]

On Fri, Nov 6, 2015 at 3:01 PM, Phil Steitz  wrote:

> On 11/6/15 2:51 PM, Gary Gregory wrote:
> >> On Fri, 6 Nov 2015 09:17:18 -0700, 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... but even-numbered lines can include breaks -
> >>>
> >> ...
> > This sounds awfully complicated for my puny human brain.
>
> How, exactly?  Seems pretty simple to me.  The even-numbered release
> lines may have compat breaks; but the odd-numbered do not.
> >
> > It's bad enough that I have to remember how each FOSS project treats
> > versions numbers, but having an exception within a Commons component is
> > even worse. This is a non-starter for me.
>
> Do you have any better suggestions?  The problem we are trying to
> solve is we can't RERO while sticking to the normal compat rules
> without turning major versions all the time, which forces users to
> repackage all the time and us to support more versions concurrently
> than we have bandwidth to do.
>

I do not see how a different version scheme will determine how many
branches the community supports.

Breaking BC without a package and coord change is a no-go. You have to
think about this jar as a dependency that can be deeply nested in a
software stack. Commons components are such creatures. I unfortunately run
into this more than I'd like: Big FOSS project A depends on B which depends
on C. Then I want to integrate with Project X which depends on Y which
depends on different versions of B and C. Welcome to jar hell if B and C
are not compatible. If B and C follow the rule of break-BC -> new
package/coords, then all is well.

Gary


>
> Phil
> >
> > Gary
> >
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [math] Version mgt idea

[Phil Steitz]

On 11/6/15 4:46 PM, Gary Gregory wrote:
> On Fri, Nov 6, 2015 at 3:01 PM, Phil Steitz  wrote:
>
>> On 11/6/15 2:51 PM, Gary Gregory wrote:
 On Fri, 6 Nov 2015 09:17:18 -0700, 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... but even-numbered lines can include breaks -
>
 ...
>>> This sounds awfully complicated for my puny human brain.
>> How, exactly?  Seems pretty simple to me.  The even-numbered release
>> lines may have compat breaks; but the odd-numbered do not.
>>> It's bad enough that I have to remember how each FOSS project treats
>>> versions numbers, but having an exception within a Commons component is
>>> even worse. This is a non-starter for me.
>> Do you have any better suggestions?  The problem we are trying to
>> solve is we can't RERO while sticking to the normal compat rules
>> without turning major versions all the time, which forces users to
>> repackage all the time and us to support more versions concurrently
>> than we have bandwidth to do.
>>
> I do not see how a different version scheme will determine how many
> branches the community supports.

If we just keep one 4.x branch that keeps cutting (possibly
incompatible) releases, that is just one line, one branch.  If we
have to cut 4.1, 4.2, 4.3 as 4, 5, 6 instead and we don't allow any
compat breaks, we end up having to maintain and release 4.0.1,
5.0.1, 6.0.1 instead of just 4.3.1, for example, or we just strand
the 4, 5 users in terms of bug fixes as we move on to 6.
>
> Breaking BC without a package and coord change is a no-go.

We have done this before and we will probably do it again - and more
if we have to don't separate out an unstable line.
>  You have to
> think about this jar as a dependency that can be deeply nested in a
> software stack. Commons components are such creatures. I unfortunately run
> into this more than I'd like: Big FOSS project A depends on B which depends
> on C. Then I want to integrate with Project X which depends on Y which
> depends on different versions of B and C. Welcome to jar hell if B and C
> are not compatible. If B and C follow the rule of break-BC -> new
> package/coords, then all is well.

The mitigation here is that we would not expect the even-numbered
releases to be deployed widely.

Phil
>
> Gary
>
>
>> Phil
>>> Gary
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Version mgt idea

[Gary Gregory]

On Fri, Nov 6, 2015 at 4:42 PM, Gilles  wrote:

> On Fri, 6 Nov 2015 17:02:01 -0700, Phil Steitz wrote:
>
>> On 11/6/15 4:46 PM, Gary Gregory wrote:
>>
>>> On Fri, Nov 6, 2015 at 3:01 PM, Phil Steitz 
>>> wrote:
>>>
>>> On 11/6/15 2:51 PM, Gary Gregory wrote:

> On Fri, 6 Nov 2015 09:17:18 -0700, 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... but even-numbered lines can include breaks -
>>>
>>> ...
>>
> This sounds awfully complicated for my puny human brain.
>
 How, exactly?  Seems pretty simple to me.  The even-numbered release
 lines may have compat breaks; but the odd-numbered do not.

> It's bad enough that I have to remember how each FOSS project treats
> versions numbers, but having an exception within a Commons component is
> even worse. This is a non-starter for me.
>
 Do you have any better suggestions?  The problem we are trying to
 solve is we can't RERO while sticking to the normal compat rules
 without turning major versions all the time, which forces users to
 repackage all the time and us to support more versions concurrently
 than we have bandwidth to do.

 I do not see how a different version scheme will determine how many
>>> branches the community supports.
>>>
>>
>> If we just keep one 4.x branch that keeps cutting (possibly
>> incompatible) releases, that is just one line, one branch.  If we
>> have to cut 4.1, 4.2, 4.3 as 4, 5, 6 instead and we don't allow any
>> compat breaks, we end up having to maintain and release 4.0.1,
>> 5.0.1, 6.0.1 instead of just 4.3.1, for example, or we just strand
>> the 4, 5 users in terms of bug fixes as we move on to 6.
>>
>>>
>>> Breaking BC without a package and coord change is a no-go.
>>>
>>
>> We have done this before and we will probably do it again - and more
>> if we have to don't separate out an unstable line.
>>
>>>  You have to
>>> think about this jar as a dependency that can be deeply nested in a
>>> software stack. Commons components are such creatures. I unfortunately
>>> run
>>> into this more than I'd like: Big FOSS project A depends on B which
>>> depends
>>> on C. Then I want to integrate with Project X which depends on Y which
>>> depends on different versions of B and C. Welcome to jar hell if B and C
>>> are not compatible. If B and C follow the rule of break-BC -> new
>>> package/coords, then all is well.
>>>
>>
>> The mitigation here is that we would not expect the even-numbered
>> releases to be deployed widely.
>>
>
> Or we can prevent any potential JAR hell by changing the top-level
> package name for every release in the unstable series:
>
> 4.0 -> org.apache.commons.math4u0
> 4.1 -> org.apache.commons.math4u1
>
> This would also offer the possibility to write a code using
> classes from several unstable releases (e.g. to compare their
> performance).


Pardon my daftness, but if you change package/coord names, what are you
gaining compared to the usual major version changes?

Gary



>
> Gilles
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [math] Version mgt idea

[Gary Gregory]

On Fri, Nov 6, 2015 at 4:02 PM, Phil Steitz  wrote:

> On 11/6/15 4:46 PM, Gary Gregory wrote:
> > On Fri, Nov 6, 2015 at 3:01 PM, Phil Steitz 
> wrote:
> >
> >> On 11/6/15 2:51 PM, Gary Gregory wrote:
>  On Fri, 6 Nov 2015 09:17:18 -0700, 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... but even-numbered lines can include breaks -
> >
>  ...
> >>> This sounds awfully complicated for my puny human brain.
> >> How, exactly?  Seems pretty simple to me.  The even-numbered release
> >> lines may have compat breaks; but the odd-numbered do not.
> >>> It's bad enough that I have to remember how each FOSS project treats
> >>> versions numbers, but having an exception within a Commons component is
> >>> even worse. This is a non-starter for me.
> >> Do you have any better suggestions?  The problem we are trying to
> >> solve is we can't RERO while sticking to the normal compat rules
> >> without turning major versions all the time, which forces users to
> >> repackage all the time and us to support more versions concurrently
> >> than we have bandwidth to do.
> >>
> > I do not see how a different version scheme will determine how many
> > branches the community supports.
>
> If we just keep one 4.x branch that keeps cutting (possibly
> incompatible) releases, that is just one line, one branch.  If we
> have to cut 4.1, 4.2, 4.3 as 4, 5, 6 instead and we don't allow any
> compat breaks, we end up having to maintain and release 4.0.1,
> 5.0.1, 6.0.1 instead of just 4.3.1, for example, or we just strand
> the 4, 5 users in terms of bug fixes as we move on to 6.
> >
> > Breaking BC without a package and coord change is a no-go.
>
> We have done this before and we will probably do it again - and more
> if we have to don't separate out an unstable line.
> >  You have to
> > think about this jar as a dependency that can be deeply nested in a
> > software stack. Commons components are such creatures. I unfortunately
> run
> > into this more than I'd like: Big FOSS project A depends on B which
> depends
> > on C. Then I want to integrate with Project X which depends on Y which
> > depends on different versions of B and C. Welcome to jar hell if B and C
> > are not compatible. If B and C follow the rule of break-BC -> new
> > package/coords, then all is well.
>
> The mitigation here is that we would not expect the even-numbered
> releases to be deployed widely.
>

Respectfully Phil, my point is that while this might be true, it is in
practice irrelevant. We cannot control the spread of our jars and their
usage, hence the importance of BC.

Gary

>
> Phil
> >
> > Gary
> >
> >
> >> Phil
> >>> Gary
> >>>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
> >
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [math] Version mgt idea

[Phil Steitz]

On 11/6/15 2:51 PM, Gary Gregory wrote:
>> On Fri, 6 Nov 2015 09:17:18 -0700, 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... but even-numbered lines can include breaks -
>>>
>> ...
> This sounds awfully complicated for my puny human brain.

How, exactly?  Seems pretty simple to me.  The even-numbered release
lines may have compat breaks; but the odd-numbered do not.
>
> It's bad enough that I have to remember how each FOSS project treats
> versions numbers, but having an exception within a Commons component is
> even worse. This is a non-starter for me.

Do you have any better suggestions?  The problem we are trying to
solve is we can't RERO while sticking to the normal compat rules
without turning major versions all the time, which forces users to
repackage all the time and us to support more versions concurrently
than we have bandwidth to do.

Phil
>
> Gary
>



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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

[Thomas Neidhart]

On 11/06/2015 10:25 PM, Bernd Eckenfels wrote:
> ello,
> 
> I came across this article:
> 
> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
> 
> It describes attacks against common Java applications with
> pre-authentication requests using malicious Java Object serialisation.
> It builds upon the work of Gabriel Lawrence (@gebl) and Chris Frohoff
> (@frohoff) (presented on January 28th, 2015, “Marshalling Pickles”
> given at AppSecCali)
> 
> http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles
> 
> The ysoserial tool has some sample payloads, two use
> commons-collection oac.collections.functors.InvokerTransformer. * 
> 
> https://github.com/frohoff/ysoserial/tree/master/src/main/java/ysoserial/payloads
> 
> The class itself is rather handy to break out of the readObject()
> chains to execute arbitrary methods.
> 
> I do'nt recall any discussion here about this
> class. Is this currently handled/reported? Of course the more general
> problem is using serialisation with untusted peers, and if
> commons-collection fixes this, there might still be other vectors, but
> still I think it would be good to do something against that "bad press"?

I was not aware of this yet, thanks for the pointers.

If we would remove the problematic classes and release a new collections
version (for the 3.x or 4.x branch) we would break source and binary
compatibility.

It might be acceptable/doable to release a collections version with an
additional maven classifier (e.g. -hardened) that removes the relevant
classes and explain the compatibility issues in detail in the release
notes. What do others think about something like that?

btw. with Java 8 you can do similar things by using serialized method
references. I did create a very simple example to illustrate the issue:

public class MyTest {

public static void main(String[] args) throws Exception {
final SAM1 m1 = (SAM1 & Serializable) Runtime::getRuntime;
final SAM2 m2 = (SAM2 & Serializable) Runtime::exec;

Transformer t1 = (Transformer & Serializable) (input) -> m1.action();
Transformer t2 = (Transformer & Serializable) (input) -> {
try {
Process p = m2.action((Runtime) input, "ls");

String line;
StringBuilder output = new StringBuilder();
BufferedReader reader = new BufferedReader(new
InputStreamReader(p.getInputStream()));
while ((line = reader.readLine()) != null) {
output.append(line);
output.append("\n");
}
reader.close();
return output.toString();
} catch (IOException e) {
return null;
}
};

ChainedTransformer chain = new ChainedTransformer(t1, t2);
TransformedList list = TransformedList.transformedList(new
ArrayList(), chain);

FileOutputStream fos = new FileOutputStream("test.ser");
ObjectOutputStream os = new ObjectOutputStream(fos);
os.writeObject(list);
os.close();

FileInputStream fis = new FileInputStream("test.ser");
ObjectInputStream ois = new ObjectInputStream(fis);

List l2 = (List)ois.readObject();

l2.add(1);

//Print the result
System.out.println(l2);
ois.close();
}

interface SAM1 {
Runtime action();
}

interface SAM2 {
Process action(Runtime r, String s) throws IOException;
}

}


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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

[Thomas Neidhart]

On 11/07/2015 12:56 AM, Thomas Neidhart wrote:
> On 11/06/2015 10:25 PM, Bernd Eckenfels wrote:
>> ello,
>>
>> I came across this article:
>>
>> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
>>
>> It describes attacks against common Java applications with
>> pre-authentication requests using malicious Java Object serialisation.
>> It builds upon the work of Gabriel Lawrence (@gebl) and Chris Frohoff
>> (@frohoff) (presented on January 28th, 2015, “Marshalling Pickles”
>> given at AppSecCali)
>>
>> http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles
>>
>> The ysoserial tool has some sample payloads, two use
>> commons-collection oac.collections.functors.InvokerTransformer. * 
>>
>> https://github.com/frohoff/ysoserial/tree/master/src/main/java/ysoserial/payloads
>>
>> The class itself is rather handy to break out of the readObject()
>> chains to execute arbitrary methods.
>>
>> I do'nt recall any discussion here about this
>> class. Is this currently handled/reported? Of course the more general
>> problem is using serialisation with untusted peers, and if
>> commons-collection fixes this, there might still be other vectors, but
>> still I think it would be good to do something against that "bad press"?
> 
> I was not aware of this yet, thanks for the pointers.
> 
> If we would remove the problematic classes and release a new collections
> version (for the 3.x or 4.x branch) we would break source and binary
> compatibility.
> 
> It might be acceptable/doable to release a collections version with an
> additional maven classifier (e.g. -hardened) that removes the relevant
> classes and explain the compatibility issues in detail in the release
> notes. What do others think about something like that?
> 
> btw. with Java 8 you can do similar things by using serialized method
> references. I did create a very simple example to illustrate the issue:
> 
> public class MyTest {
> 
>   public static void main(String[] args) throws Exception {
>   final SAM1 m1 = (SAM1 & Serializable) Runtime::getRuntime;
>   final SAM2 m2 = (SAM2 & Serializable) Runtime::exec;
>   
>   Transformer t1 = (Transformer & Serializable) (input) -> m1.action();
>   Transformer t2 = (Transformer & Serializable) (input) -> {
>   try {
>   Process p = m2.action((Runtime) input, "ls");
>   
>   String line;
>   StringBuilder output = new StringBuilder();
>   BufferedReader reader = new BufferedReader(new
> InputStreamReader(p.getInputStream()));
>   while ((line = reader.readLine()) != null) {
>   output.append(line);
>   output.append("\n");
>   }
>   reader.close();
>   return output.toString();
>   } catch (IOException e) {
>   return null;
>   }
>   };
> 
>   ChainedTransformer chain = new ChainedTransformer(t1, t2);
>   TransformedList list = TransformedList.transformedList(new
> ArrayList(), chain);
> 
> FileOutputStream fos = new FileOutputStream("test.ser");
> ObjectOutputStream os = new ObjectOutputStream(fos);
> os.writeObject(list);
> os.close();
> 
> FileInputStream fis = new FileInputStream("test.ser");
> ObjectInputStream ois = new ObjectInputStream(fis);
> 
> List l2 = (List)ois.readObject();
> 
> l2.add(1);
> 
> //Print the result
> System.out.println(l2);
> ois.close();
> }
> 
> interface SAM1 {
>   Runtime action();
> }
> 
> interface SAM2 {
> Process action(Runtime r, String s) throws IOException;
> }
> 

I was a bit too fast with this. This example will only work if the
remote site has the same code otherwise the lambda functions can not be
de-serialized.

Thomas

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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

[Bernd Eckenfels]

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 vectors. This was also addressed by the
original authors in the talk and even here on Twitter:

https://twitter.com/gebl/status/662754611304996866

however, as the "foxglove" article shows, people still point at the
apache project, and after all it is good pratice to reduce footprints
and attack surfaces.

So it seems to be a good idea to discuss some hardening. Unfortunatelly
having a hardened distribution with only this one class removed might
be a bit overkill. Are there other candidates to be left out in such a
more specific distribution? Maybe everything proxy/reflection related?

Both sample payloads have "gadget chains" which do start (readObject())
in JCL classes and then use pretty generic interfaces like Annotations
or Comparators, so there is really no link between the types and the
specific weakness.

Greetings
Bernd


 Am Sat, 7 Nov 2015 00:56:00 +0100
schrieb Thomas Neidhart :

> On 11/06/2015 10:25 PM, Bernd Eckenfels wrote:
> > ello,
> > 
> > I came across this article:
> > 
> > http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
> > 
> > It describes attacks against common Java applications with
> > pre-authentication requests using malicious Java Object
> > serialisation. It builds upon the work of Gabriel Lawrence (@gebl)
> > and Chris Frohoff (@frohoff) (presented on January 28th, 2015,
> > “Marshalling Pickles” given at AppSecCali)
> > 
> > http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles
> > 
> > The ysoserial tool has some sample payloads, two use
> > commons-collection oac.collections.functors.InvokerTransformer. * 
> > 
> > https://github.com/frohoff/ysoserial/tree/master/src/main/java/ysoserial/payloads
> > 
> > The class itself is rather handy to break out of the readObject()
> > chains to execute arbitrary methods.
> > 
> > I do'nt recall any discussion here about this
> > class. Is this currently handled/reported? Of course the more
> > general problem is using serialisation with untusted peers, and if
> > commons-collection fixes this, there might still be other vectors,
> > but still I think it would be good to do something against that
> > "bad press"?
> 
> I was not aware of this yet, thanks for the pointers.
> 
> If we would remove the problematic classes and release a new
> collections version (for the 3.x or 4.x branch) we would break source
> and binary compatibility.
> 
> It might be acceptable/doable to release a collections version with an
> additional maven classifier (e.g. -hardened) that removes the relevant
> classes and explain the compatibility issues in detail in the release
> notes. What do others think about something like that?
...

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Releasing 4.0? (Was: releasing 3.6 ?)

[luc]

Le 2015-11-06 02:34, Gilles a écrit :

On Thu, 5 Nov 2015 15:41:57 -0700, Phil Steitz wrote:

On 11/5/15 1:58 PM, Luc Maisonobe wrote:

Le 05/11/2015 12:25, Gilles a écrit :

Hello.

On Wed, 04 Nov 2015 10:13:00 +0100, luc wrote:

Hi all,

I would like to release 3.6 in the upcoming weeks.
There have been a bunch of bug fixes and a few evolutions that are
important to me.

s/3.6/4.0/

And the statement is still true.


[...]

Of course, once 3.6 is out the MATH_3_X branch will remain alive 
and

we could also release other versions later on in the 3.x series.
Should we worry that the next major release will be endlessly 
delayed?
I think we are really quite far from releasing 4.0 as in many 
packages
we did not even start refactoring API. Optimization is clearly the 
most
well known example, but there are also other things waiting in the 
pipe

for geometry and ode.


Is there any specific target for 4.0?


Yes, at least having changed public API.


Could we judge how far we are from releasing a major release with the
same arguments which you used for 3.6 (many additions, bug fixes,
things someone would like to use, etc.)?

4.0 does not need to be perfect. [3.0 was supposed to be perfect ;-).]
4.1 will be!  Or 4.2, or 5.0...


4.x for x > 1 will have exactly the same problems as 4.0 API-wise since
once 4.0 is out the API will be fixed.



Let's not forget that we agreed to work towards 4.0, and that the 3.x
branch was an afterthought.


I agree and was slightly reluctant to continue on 3.X at that time. 
Deciding
to still keep this branch was indeed a good idea. I properly address the 
problem

that we did not find time to work on 4.0 as we wanted.



Since we now effectively maintain two versions of CM, it makes sense
to allow people to benefit from the extra work.


Yes, but our own overzealous rule about compatibility (I can take the
blame here, I am guilty for this) induces that we change API only when
major versions are published. We do have the opportunity to do this for
4.0, lets use it at least and not again postpone needed changes. Our 3.X
API sucks in many places and we know it.



My viewpoint is that we can have releases from both branches, making
it clear what is old/deprecated/broken in 3.x and what is still
missing in 4.y.


If it were only missing features, that can be added, I would agree. 
However

some of the changes are really modifications of existing interfaces.




I agree on this.  One thing I forgot to mention above is I think we
may have a few places in 3.x optimization where every way to do
something is deprecated.  I suggest we take a careful look and
undeprecate where necessary to make 3.6 usable without warnings.  I
may be wrong since I don't use that code myself; but I think its
worth taking a careful look and considering removal of some
deprecations.


I'm against this.  And is why I started the sure-to-be-controversial
discussion on 4.0.


I also don't really like the idea of undeprecating these things.



We agreed that things were (relatively) broken, and we agreed on a
way forward (fluent API, refactoring of the "optim" classes); yet
things don't move, because there is no urge to fix them since new
features can be back-ported indefinitely to the 3.x series.


No, things don't move because I didn't find time. I am really,
really busy doing lots of different stuff. I am also really, really
aware this API should be improved and fluent API is still a way I would
like to explore for this. And no, I am not sure this will work and
4.x will see the end of these problems.



Undeprecating what we agreed should be deprecated would only
reinforce that feeling, and certainly won't attract attention that
we need help to make progress.
[And, in addition, 3.x is tied to old Java5 (known tune)...]

In summary, I think that new features should only go to the master
branch, while only bug-fixes would be back-ported to MATH_3_X.
Thus everybody can have the best of both, while reducing the
amount of work for the developers.  Continuing in this way, and
we'll soon have to also "forward-port" bugs reported against the
3.x series. :-/


Hey, I already do that! The following one-liner is my new
favorite:

  git diff -p MATH_3_X~1 MATH_3_X | sed 's,math3,math4,g' | patch -p1

Yes, it is cumbersome.

best regards,
Luc




Gilles


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Outdated Information on Jira Summary Page

[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 plans for major work on the 2.x line, but bug fix
> releases are made.
> Lang 3.4 - Next release from 3.x branch.
>
> There haven't been any 2.x release for a few years, so this is misleading.
> 3.4 was released on months ago.
>
> It would be nice if somebody could update this.
>

I've corrected the next release version to 3.5. We keep the 2.x version,
because we may release a new version if critical issues show up. But there
is no active development anymore.

Thank you!
Benedikt


>
> Thanks,
> Pascal
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [math] Version mgt idea

[sebb]

On 6 November 2015 at 16:17, 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... but even-numbered lines can include breaks - so 4.0 and 4.1
> might not be compatible.  We would always maintain both an odd and
> even branch - ideally in such a way that when an even numbered line
> stabilized it would add a last hurrah of breaks and move to odd.
> People wanting stable APIs could just stick with the odd-numbered
> lines and [math] developers wanting to experiment with things and
> not worry about compatibility could do that in the even-numbered
> lines.  In effect, this is sort of what we are doing now in 3.x / 4.x.
>
> I know above violates Commons policy if we actually cut releases
> from the even-numbered branches - we would have to get agreement
> from the Commons PMC that this is OK or somehow label the releases
> differently.  Just an idea to get us out of our current bind...

That would likely cause problems with Maven, which will pick the
latest release, regardless of whether it is even or odd.
[However changing the gid/uid without changing the package name also
causes problems with Maven.]

Unless it is possible to add a marker to the release such that Maven
does not consider it when looking for the latest release.
The only such marker I know of is SNAPSHOT - such releases are not
added to Maven Central so cannot be accidentally added to the
classpath.

Maybe there is another marker which could be used that tells Maven not
to consider that version.

If there is no other such marker, one way to avoid these issues would
be to not publish the even releases to Maven Central.
Users would have to download them some other way.

Maybe there is mileage in having a staging repo for Commons as a half-way house.
Users would need to specifically add the repo to their pom to use the repo.
[I think I suggested something like this for some Commons Maven
plugins that were for developer use only]

Note that publishing even-numbered releases to the ASF mirror service
can also cause problems if the unstable releases are not clearly
marked.

> Phil
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Version mgt idea

[Phil Steitz]

On 11/6/15 11:02 AM, Gilles wrote:
> On Fri, 6 Nov 2015 10:36:51 -0700, Phil Steitz wrote:
>> On 11/6/15 10:31 AM, Gilles wrote:
>>> Hi.
>>>
>>> On Fri, 6 Nov 2015 09:17:18 -0700, 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... but even-numbered lines can include breaks -
>>>
>>> I like the proposal to be more lax on compatibility breaking than
>>> I ever dreamed of.  ;-)
>>>
 so 4.0 and 4.1
 might not be compatible.
>>>
>>> Isn't that going to cause JAR hell?
>>
>> Yes, within the even-numbered branches.  But we would repackage and
>> rename at each version cut as we do now.
>
> I don't follow.
> Is top-level package renaming in order: e.g.
> "org.apache.commons.math4m0" for 4.0
> "org.apache.commons.math4m1" for 4.1
> ?

Sorry, I was not clear.  I meant that we would do the repackaging
only at major release, so both above would be .math4


>
> This would be akin to the "experimental" package idea evoked
> in an earlier incarnation of this discussion.
>
>> So the only "hell" would
>> be if someone deploys multiple different versions from an
>> even-numbered branch.  We would expect them to be less widely
>> deployed, so this would be less of an issue.
>
> I don't follow either.
> What issue did you intend to solve with the proposal?

Basically, limit the compat breaks to lines "known" to contain breaks.
>
> My wish is that all (users and developers) can enjoy a timely
> official release of the "bleeding edge"; whereas it now seems
> to me that you are only talking about branch naming.
> [And even-numbered ones will likely not be released because
> of JAR hell.]

That is what I was trying to support.  RERO with constant API change
means you have to release API breaks often.  That's the crux of our
problem with 4.0 now.  If we want it to have a stable API, we need
to finish stabilizing it before we release anything; otherwise we
need to follow immediately with 5, 6 etc.  What I was suggesting is
that we could just advertise the fact that the 4.x API is not
expected to be stable.  Once it stabilizes, it will become 5.x. 
This has the advantage that users wanting a stable API know what to
use and we only have to support 2 lines at any given time. 

Phil
>
> Or what did I miss?
>
> Gilles
>
>>
>> Phil
>>>
>>> Gilles
>>>
 We would always maintain both an odd and
 even branch - ideally in such a way that when an even numbered
 line
 stabilized it would add a last hurrah of breaks and move to odd.
 People wanting stable APIs could just stick with the odd-numbered
 lines and [math] developers wanting to experiment with things and
 not worry about compatibility could do that in the even-numbered
 lines.  In effect, this is sort of what we are doing now in 3.x /
 4.x.

 I know above violates Commons policy if we actually cut releases
 from the even-numbered branches - we would have to get agreement
 from the Commons PMC that this is OK or somehow label the releases
 differently.  Just an idea to get us out of our current bind...

 Phil
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Version mgt idea

[Luc Maisonobe]

Le 06/11/2015 18:18, sebb a écrit :
> On 6 November 2015 at 16:17, 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... but even-numbered lines can include breaks - so 4.0 and 4.1
>> might not be compatible.  We would always maintain both an odd and
>> even branch - ideally in such a way that when an even numbered line
>> stabilized it would add a last hurrah of breaks and move to odd.
>> People wanting stable APIs could just stick with the odd-numbered
>> lines and [math] developers wanting to experiment with things and
>> not worry about compatibility could do that in the even-numbered
>> lines.  In effect, this is sort of what we are doing now in 3.x / 4.x.
>>
>> I know above violates Commons policy if we actually cut releases
>> from the even-numbered branches - we would have to get agreement
>> from the Commons PMC that this is OK or somehow label the releases
>> differently.  Just an idea to get us out of our current bind...
> 
> That would likely cause problems with Maven, which will pick the
> latest release, regardless of whether it is even or odd.

No because we change the artifact coordinates too.
So people who depend on apache.commons.math3 will never see
artifacts from the apache.commons.math4 series.

> [However changing the gid/uid without changing the package name also
> causes problems with Maven.]
> 
> Unless it is possible to add a marker to the release such that Maven
> does not consider it when looking for the latest release.
> The only such marker I know of is SNAPSHOT - such releases are not
> added to Maven Central so cannot be accidentally added to the
> classpath.
> 
> Maybe there is another marker which could be used that tells Maven not
> to consider that version.
> 
> If there is no other such marker, one way to avoid these issues would
> be to not publish the even releases to Maven Central.
> Users would have to download them some other way.
> 
> Maybe there is mileage in having a staging repo for Commons as a half-way 
> house.
> Users would need to specifically add the repo to their pom to use the repo.
> [I think I suggested something like this for some Commons Maven
> plugins that were for developer use only]
> 
> Note that publishing even-numbered releases to the ASF mirror service
> can also cause problems if the unstable releases are not clearly
> marked.
> 
>> Phil
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Version mgt idea

[Luc Maisonobe]

Le 06/11/2015 18:31, Gilles a écrit :
> Hi.
> 
> On Fri, 6 Nov 2015 09:17:18 -0700, 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... but even-numbered lines can include breaks -
> 
> I like the proposal to be more lax on compatibility breaking than
> I ever dreamed of.  ;-)

Yeah, good idea!
Go for it.

> 
>> so 4.0 and 4.1
>> might not be compatible.
> 
> Isn't that going to cause JAR hell?

As long as people are aware there are no compliance implied,
then they know what they have to do when they decide to
use this.

best regards,
Luc

> 
> Gilles
> 
>> We would always maintain both an odd and
>> even branch - ideally in such a way that when an even numbered line
>> stabilized it would add a last hurrah of breaks and move to odd.
>> People wanting stable APIs could just stick with the odd-numbered
>> lines and [math] developers wanting to experiment with things and
>> not worry about compatibility could do that in the even-numbered
>> lines.  In effect, this is sort of what we are doing now in 3.x / 4.x.
>>
>> I know above violates Commons policy if we actually cut releases
>> from the even-numbered branches - we would have to get agreement
>> from the Commons PMC that this is OK or somehow label the releases
>> differently.  Just an idea to get us out of our current bind...
>>
>> Phil
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Releasing 4.0? (Was: releasing 3.6 ?)

[Luc Maisonobe]

Le 06/11/2015 14:55, Gilles a écrit :
> Hi Luc.
> 
> On Fri, 06 Nov 2015 10:04:23 +0100, luc wrote:
>> Le 2015-11-06 02:34, Gilles a écrit :
>>> On Thu, 5 Nov 2015 15:41:57 -0700, Phil Steitz wrote:
 On 11/5/15 1:58 PM, Luc Maisonobe wrote:
> Le 05/11/2015 12:25, Gilles a écrit :
>> Hello.
>> On Wed, 04 Nov 2015 10:13:00 +0100, luc wrote:
>>> Hi all,
>>> I would like to release 3.6 in the upcoming weeks.
>>> There have been a bunch of bug fixes and a few evolutions that are
>>> important to me.
>> s/3.6/4.0/
>> And the statement is still true.
>>
>>> [...]
>>> Of course, once 3.6 is out the MATH_3_X branch will remain alive and
>>> we could also release other versions later on in the 3.x series.
>> Should we worry that the next major release will be endlessly
>> delayed?
> I think we are really quite far from releasing 4.0 as in many packages
> we did not even start refactoring API. Optimization is clearly the
> most
> well known example, but there are also other things waiting in the
> pipe
> for geometry and ode.
>>> Is there any specific target for 4.0?
>>
>> Yes, at least having changed public API.
> 
> There are two parts to that task: delete the deprecated code, and provide
> the same (or better) functionality with new code.

Not only that.
When an interface intended to be implemented by users is changed
(say FirstOrderDifferentialEquations for example, then as soon as a
user update to the version after the change, all its implementations
have to be changed at once.

> I thought that the "delete" updates had been performed by Thomas.
> Is there anything else that must go, but still is in master, and is not
> deprecated in MATH_3_X?

Yes, at least in ode (interface changes) and geometry (semantic changes).

> If so, a JIRA "task" issue should indicate what to do, and this should be
> resolved before release (IMHO).

OK for a JIRA task, but we cannot deprecate the user interfaces involved.

> 
>>> Could we judge how far we are from releasing a major release with the
>>> same arguments which you used for 3.6 (many additions, bug fixes,
>>> things someone would like to use, etc.)?
>>> 4.0 does not need to be perfect. [3.0 was supposed to be perfect ;-).]
>>> 4.1 will be!  Or 4.2, or 5.0...
>>
>> 4.x for x > 1 will have exactly the same problems as 4.0 API-wise since
>> once 4.0 is out the API will be fixed.
> 
> Yes, but I mean that
> 1. we should list all agreed changes even if they are not implemented
>(like for "optim"),
> 2. then, the scene is set for 4.0 (and the release could indeed miss
>many bits, for which users will need 3.6),
> 2. we can add classes and methods in 4.x (x > 0), and where not
>possible (Java "interface"), then we'll go on and create 5.x.
> [As someone said, plenty of integers left...]

With Phil proposal to use an even/odd scheme, things become simpler.

> 
> "Release early, release often".
> We still do neither.
> Despite several developers agreeing on the principle, I'm being put in
> the position to argue against "Release later"...
> 
>>> Let's not forget that we agreed to work towards 4.0, and that the 3.x
>>> branch was an afterthought.
>>
>> I agree and was slightly reluctant to continue on 3.X at that time.
>> Deciding
>> to still keep this branch was indeed a good idea. I properly address
>> the problem
>> that we did not find time to work on 4.0 as we wanted.
> 
> I've mixed feelings about MATH_3_X.  I now realize that I had unconsciously
> imagined that it would be short-lived (so the few new features introduced
> during that period could indeed be routinely back-ported).
> 
> Providing longer-term bug-fix support is a good thing.
> Back-porting everything is IMO definitely a bad idea.
> 
>>> Since we now effectively maintain two versions of CM, it makes sense
>>> to allow people to benefit from the extra work.
>>
>> Yes, but our own overzealous rule about compatibility (I can take the
>> blame here, I am guilty for this) induces that we change API only when
>> major versions are published. We do have the opportunity to do this for
>> 4.0, lets use it at least and not again postpone needed changes. Our 3.X
>> API sucks in many places and we know it.
> 
> 4.0 will be pristine (w.r.t our current view on the design): no ugly API
> since all that suck should have been deleted!

Yes, but as explained above, we need to provide also support for the
new user interfaces. Typically if FirstOrderDifferentialEquations as
well as two or three other user interfaces change in ode, all our
ode code should support all these changes as soon as 4.0.

> 
>>> My viewpoint is that we can have releases from both branches, making
>>> it clear what is old/deprecated/broken in 3.x and what is still
>>> missing in 4.y.
>>
>> If it were only missing features, that can be added, I would agree.
>> However
>> some of the changes are really modifications of existing interfaces.
> 
> Fine, if this is 

[math] Version mgt idea

[Phil Steitz]

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... but even-numbered lines can include breaks - so 4.0 and 4.1
might not be compatible.  We would always maintain both an odd and
even branch - ideally in such a way that when an even numbered line
stabilized it would add a last hurrah of breaks and move to odd. 
People wanting stable APIs could just stick with the odd-numbered
lines and [math] developers wanting to experiment with things and
not worry about compatibility could do that in the even-numbered
lines.  In effect, this is sort of what we are doing now in 3.x / 4.x.

I know above violates Commons policy if we actually cut releases
from the even-numbered branches - we would have to get agreement
from the Commons PMC that this is OK or somehow label the releases
differently.  Just an idea to get us out of our current bind...

Phil


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Releasing 4.0? (Was: releasing 3.6 ?)

[Gilles]

On Fri, 6 Nov 2015 07:02:58 -0700, Phil Steitz wrote:

On 11/6/15 2:04 AM, luc wrote:

Le 2015-11-06 02:34, Gilles a écrit :

On Thu, 5 Nov 2015 15:41:57 -0700, Phil Steitz wrote:

On 11/5/15 1:58 PM, Luc Maisonobe wrote:

Le 05/11/2015 12:25, Gilles a écrit :

Hello.

On Wed, 04 Nov 2015 10:13:00 +0100, luc wrote:

Hi all,

I would like to release 3.6 in the upcoming weeks.
There have been a bunch of bug fixes and a few evolutions
that are
important to me.

s/3.6/4.0/

And the statement is still true.


[...]

Of course, once 3.6 is out the MATH_3_X branch will remain
alive and
we could also release other versions later on in the 3.x 
series.

Should we worry that the next major release will be endlessly
delayed?

I think we are really quite far from releasing 4.0 as in many
packages
we did not even start refactoring API. Optimization is clearly
the most
well known example, but there are also other things waiting in
the pipe
for geometry and ode.


Is there any specific target for 4.0?


Yes, at least having changed public API.


Could we judge how far we are from releasing a major release with
the
same arguments which you used for 3.6 (many additions, bug fixes,
things someone would like to use, etc.)?

4.0 does not need to be perfect. [3.0 was supposed to be perfect
;-).]
4.1 will be!  Or 4.2, or 5.0...


4.x for x > 1 will have exactly the same problems as 4.0 API-wise
since
once 4.0 is out the API will be fixed.



Let's not forget that we agreed to work towards 4.0, and that the
3.x
branch was an afterthought.


I agree and was slightly reluctant to continue on 3.X at that
time. Deciding
to still keep this branch was indeed a good idea. I properly
address the problem
that we did not find time to work on 4.0 as we wanted.



Since we now effectively maintain two versions of CM, it makes 
sense

to allow people to benefit from the extra work.


Yes, but our own overzealous rule about compatibility (I can take 
the

blame here, I am guilty for this) induces that we change API only
when
major versions are published. We do have the opportunity to do
this for
4.0, lets use it at least and not again postpone needed changes.
Our 3.X
API sucks in many places and we know it.



My viewpoint is that we can have releases from both branches, 
making

it clear what is old/deprecated/broken in 3.x and what is still
missing in 4.y.


If it were only missing features, that can be added, I would
agree. However
some of the changes are really modifications of existing interfaces.



I agree on this.  One thing I forgot to mention above is I think 
we

may have a few places in 3.x optimization where every way to do
something is deprecated.  I suggest we take a careful look and
undeprecate where necessary to make 3.6 usable without warnings.  
I

may be wrong since I don't use that code myself; but I think its
worth taking a careful look and considering removal of some
deprecations.


I'm against this.  And is why I started the 
sure-to-be-controversial

discussion on 4.0.


I also don't really like the idea of undeprecating these things.



We agreed that things were (relatively) broken, and we agreed on a
way forward (fluent API, refactoring of the "optim" classes); yet
things don't move, because there is no urge to fix them since new
features can be back-ported indefinitely to the 3.x series.


No, things don't move because I didn't find time. I am really,
really busy doing lots of different stuff. I am also really, really
aware this API should be improved and fluent API is still a way I
would
like to explore for this. And no, I am not sure this will work and
4.x will see the end of these problems.



Undeprecating what we agreed should be deprecated would only
reinforce that feeling, and certainly won't attract attention that
we need help to make progress.
[And, in addition, 3.x is tied to old Java5 (known tune)...]

In summary, I think that new features should only go to the master
branch, while only bug-fixes would be back-ported to MATH_3_X.
Thus everybody can have the best of both, while reducing the
amount of work for the developers.  Continuing in this way, and
we'll soon have to also "forward-port" bugs reported against the
3.x series. :-/


Hey, I already do that! The following one-liner is my new
favorite:

  git diff -p MATH_3_X~1 MATH_3_X | sed 's,math3,math4,g' | patch 
-p1


Yes, it is cumbersome.


I am as busy and over-subscribed as anyone and agree it is a little
cumbersome; but I am happy to do it so users can have something
stable to work with.


Do you offer to do it for all the commits *I* might push to the
"master" branch?
That would be nice; thank you!

But is only part of the request: that new features exist in 3.x
should not frustrate those of use who would like to rely on an
official release of compatibility-breaking features.


Realize that they too are very busy and much
as we may like to ponder over the best way to keep refactoring our
API, they just want to solve practical problems (why 

Re: [math] Version mgt idea

[Phil Steitz]

On 11/6/15 10:18 AM, sebb wrote:
> On 6 November 2015 at 16:17, 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... but even-numbered lines can include breaks - so 4.0 and 4.1
>> might not be compatible.  We would always maintain both an odd and
>> even branch - ideally in such a way that when an even numbered line
>> stabilized it would add a last hurrah of breaks and move to odd.
>> People wanting stable APIs could just stick with the odd-numbered
>> lines and [math] developers wanting to experiment with things and
>> not worry about compatibility could do that in the even-numbered
>> lines.  In effect, this is sort of what we are doing now in 3.x / 4.x.
>>
>> I know above violates Commons policy if we actually cut releases
>> from the even-numbered branches - we would have to get agreement
>> from the Commons PMC that this is OK or somehow label the releases
>> differently.  Just an idea to get us out of our current bind...
> That would likely cause problems with Maven, which will pick the
> latest release, regardless of whether it is even or odd.
> [However changing the gid/uid without changing the package name also
> causes problems with Maven.]

I am curious how many people actually use unversioned dependencies. 
I would never do that.  But I get the concern that as soon as you
release an even-numbered release it becomes the latest release and
people might just grab it.
>
> Unless it is possible to add a marker to the release such that Maven
> does not consider it when looking for the latest release.
> The only such marker I know of is SNAPSHOT - such releases are not
> added to Maven Central so cannot be accidentally added to the
> classpath.
>
> Maybe there is another marker which could be used that tells Maven not
> to consider that version.
>
> If there is no other such marker, one way to avoid these issues would
> be to not publish the even releases to Maven Central.
> Users would have to download them some other way.
>
> Maybe there is mileage in having a staging repo for Commons as a half-way 
> house.
> Users would need to specifically add the repo to their pom to use the repo.
> [I think I suggested something like this for some Commons Maven
> plugins that were for developer use only]
>
> Note that publishing even-numbered releases to the ASF mirror service
> can also cause problems if the unstable releases are not clearly
> marked.

Right - there we could mark them.  We could make it clear in release
notes, READMEs, web pages, etc.

Phil
>
>> Phil
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Version mgt idea

[Phil Steitz]

On 11/6/15 10:31 AM, Gilles wrote:
> Hi.
>
> On Fri, 6 Nov 2015 09:17:18 -0700, 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... but even-numbered lines can include breaks -
>
> I like the proposal to be more lax on compatibility breaking than
> I ever dreamed of.  ;-)
>
>> so 4.0 and 4.1
>> might not be compatible.
>
> Isn't that going to cause JAR hell?

Yes, within the even-numbered branches.  But we would repackage and
rename at each version cut as we do now.  So the only "hell" would
be if someone deploys multiple different versions from an
even-numbered branch.  We would expect them to be less widely
deployed, so this would be less of an issue.

Phil
>
> Gilles
>
>> We would always maintain both an odd and
>> even branch - ideally in such a way that when an even numbered line
>> stabilized it would add a last hurrah of breaks and move to odd.
>> People wanting stable APIs could just stick with the odd-numbered
>> lines and [math] developers wanting to experiment with things and
>> not worry about compatibility could do that in the even-numbered
>> lines.  In effect, this is sort of what we are doing now in 3.x /
>> 4.x.
>>
>> I know above violates Commons policy if we actually cut releases
>> from the even-numbered branches - we would have to get agreement
>> from the Commons PMC that this is OK or somehow label the releases
>> differently.  Just an idea to get us out of our current bind...
>>
>> Phil
>>
>>
>> -
>>
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Releasing 4.0? (Was: releasing 3.6 ?)

[Gilles]

Hi Luc.

On Fri, 06 Nov 2015 10:04:23 +0100, luc wrote:

Le 2015-11-06 02:34, Gilles a écrit :

On Thu, 5 Nov 2015 15:41:57 -0700, Phil Steitz wrote:

On 11/5/15 1:58 PM, Luc Maisonobe wrote:

Le 05/11/2015 12:25, Gilles a écrit :

Hello.
On Wed, 04 Nov 2015 10:13:00 +0100, luc wrote:

Hi all,
I would like to release 3.6 in the upcoming weeks.
There have been a bunch of bug fixes and a few evolutions that 
are

important to me.

s/3.6/4.0/
And the statement is still true.


[...]
Of course, once 3.6 is out the MATH_3_X branch will remain alive 
and

we could also release other versions later on in the 3.x series.
Should we worry that the next major release will be endlessly 
delayed?
I think we are really quite far from releasing 4.0 as in many 
packages
we did not even start refactoring API. Optimization is clearly the 
most
well known example, but there are also other things waiting in the 
pipe

for geometry and ode.

Is there any specific target for 4.0?


Yes, at least having changed public API.


There are two parts to that task: delete the deprecated code, and 
provide

the same (or better) functionality with new code.
I thought that the "delete" updates had been performed by Thomas.
Is there anything else that must go, but still is in master, and is not
deprecated in MATH_3_X?
If so, a JIRA "task" issue should indicate what to do, and this should 
be

resolved before release (IMHO).

Could we judge how far we are from releasing a major release with 
the

same arguments which you used for 3.6 (many additions, bug fixes,
things someone would like to use, etc.)?
4.0 does not need to be perfect. [3.0 was supposed to be perfect 
;-).]

4.1 will be!  Or 4.2, or 5.0...


4.x for x > 1 will have exactly the same problems as 4.0 API-wise 
since

once 4.0 is out the API will be fixed.


Yes, but I mean that
1. we should list all agreed changes even if they are not implemented
   (like for "optim"),
2. then, the scene is set for 4.0 (and the release could indeed miss
   many bits, for which users will need 3.6),
2. we can add classes and methods in 4.x (x > 0), and where not
   possible (Java "interface"), then we'll go on and create 5.x.
[As someone said, plenty of integers left...]

"Release early, release often".
We still do neither.
Despite several developers agreeing on the principle, I'm being put in
the position to argue against "Release later"...

Let's not forget that we agreed to work towards 4.0, and that the 
3.x

branch was an afterthought.


I agree and was slightly reluctant to continue on 3.X at that time. 
Deciding

to still keep this branch was indeed a good idea. I properly address
the problem
that we did not find time to work on 4.0 as we wanted.


I've mixed feelings about MATH_3_X.  I now realize that I had 
unconsciously
imagined that it would be short-lived (so the few new features 
introduced

during that period could indeed be routinely back-ported).

Providing longer-term bug-fix support is a good thing.
Back-porting everything is IMO definitely a bad idea.


Since we now effectively maintain two versions of CM, it makes sense
to allow people to benefit from the extra work.


Yes, but our own overzealous rule about compatibility (I can take the
blame here, I am guilty for this) induces that we change API only 
when
major versions are published. We do have the opportunity to do this 
for
4.0, lets use it at least and not again postpone needed changes. Our 
3.X

API sucks in many places and we know it.


4.0 will be pristine (w.r.t our current view on the design): no ugly 
API

since all that suck should have been deleted!


My viewpoint is that we can have releases from both branches, making
it clear what is old/deprecated/broken in 3.x and what is still
missing in 4.y.


If it were only missing features, that can be added, I would agree. 
However

some of the changes are really modifications of existing interfaces.


Fine, if this is in the pipe...
But I'd insist that we clearly separate the issues of "complete" 
refactoring

from other modifications.
E.g. "optim" must be refactored, and that can be done in 4.x (x > 0)
because we (re)start from scratch.


I agree on this.  One thing I forgot to mention above is I think we
may have a few places in 3.x optimization where every way to do
something is deprecated.  I suggest we take a careful look and
undeprecate where necessary to make 3.6 usable without warnings.  I
may be wrong since I don't use that code myself; but I think its
worth taking a careful look and considering removal of some
deprecations.

I'm against this.  And is why I started the sure-to-be-controversial
discussion on 4.0.


I also don't really like the idea of undeprecating these things.


We agreed that things were (relatively) broken, and we agreed on a
way forward (fluent API, refactoring of the "optim" classes); yet
things don't move, because there is no urge to fix them since new
features can be back-ported indefinitely to the 3.x series.


No, things don't 

Re: [Math] Releasing 4.0? (Was: releasing 3.6 ?)

[Phil Steitz]

On 11/6/15 2:04 AM, luc wrote:
> Le 2015-11-06 02:34, Gilles a écrit :
>> On Thu, 5 Nov 2015 15:41:57 -0700, Phil Steitz wrote:
>>> On 11/5/15 1:58 PM, Luc Maisonobe wrote:
 Le 05/11/2015 12:25, Gilles a écrit :
> Hello.
>
> On Wed, 04 Nov 2015 10:13:00 +0100, luc wrote:
>> Hi all,
>>
>> I would like to release 3.6 in the upcoming weeks.
>> There have been a bunch of bug fixes and a few evolutions
>> that are
>> important to me.
> s/3.6/4.0/
>
> And the statement is still true.
>
>> [...]
>>
>> Of course, once 3.6 is out the MATH_3_X branch will remain
>> alive and
>> we could also release other versions later on in the 3.x series.
> Should we worry that the next major release will be endlessly
> delayed?
 I think we are really quite far from releasing 4.0 as in many
 packages
 we did not even start refactoring API. Optimization is clearly
 the most
 well known example, but there are also other things waiting in
 the pipe
 for geometry and ode.
>>
>> Is there any specific target for 4.0?
>
> Yes, at least having changed public API.
>
>> Could we judge how far we are from releasing a major release with
>> the
>> same arguments which you used for 3.6 (many additions, bug fixes,
>> things someone would like to use, etc.)?
>>
>> 4.0 does not need to be perfect. [3.0 was supposed to be perfect
>> ;-).]
>> 4.1 will be!  Or 4.2, or 5.0...
>
> 4.x for x > 1 will have exactly the same problems as 4.0 API-wise
> since
> once 4.0 is out the API will be fixed.
>
>>
>> Let's not forget that we agreed to work towards 4.0, and that the
>> 3.x
>> branch was an afterthought.
>
> I agree and was slightly reluctant to continue on 3.X at that
> time. Deciding
> to still keep this branch was indeed a good idea. I properly
> address the problem
> that we did not find time to work on 4.0 as we wanted.
>
>>
>> Since we now effectively maintain two versions of CM, it makes sense
>> to allow people to benefit from the extra work.
>
> Yes, but our own overzealous rule about compatibility (I can take the
> blame here, I am guilty for this) induces that we change API only
> when
> major versions are published. We do have the opportunity to do
> this for
> 4.0, lets use it at least and not again postpone needed changes.
> Our 3.X
> API sucks in many places and we know it.
>
>>
>> My viewpoint is that we can have releases from both branches, making
>> it clear what is old/deprecated/broken in 3.x and what is still
>> missing in 4.y.
>
> If it were only missing features, that can be added, I would
> agree. However
> some of the changes are really modifications of existing interfaces.
>
>>
>>> I agree on this.  One thing I forgot to mention above is I think we
>>> may have a few places in 3.x optimization where every way to do
>>> something is deprecated.  I suggest we take a careful look and
>>> undeprecate where necessary to make 3.6 usable without warnings.  I
>>> may be wrong since I don't use that code myself; but I think its
>>> worth taking a careful look and considering removal of some
>>> deprecations.
>>
>> I'm against this.  And is why I started the sure-to-be-controversial
>> discussion on 4.0.
>
> I also don't really like the idea of undeprecating these things.
>
>>
>> We agreed that things were (relatively) broken, and we agreed on a
>> way forward (fluent API, refactoring of the "optim" classes); yet
>> things don't move, because there is no urge to fix them since new
>> features can be back-ported indefinitely to the 3.x series.
>
> No, things don't move because I didn't find time. I am really,
> really busy doing lots of different stuff. I am also really, really
> aware this API should be improved and fluent API is still a way I
> would
> like to explore for this. And no, I am not sure this will work and
> 4.x will see the end of these problems.
>
>>
>> Undeprecating what we agreed should be deprecated would only
>> reinforce that feeling, and certainly won't attract attention that
>> we need help to make progress.
>> [And, in addition, 3.x is tied to old Java5 (known tune)...]
>>
>> In summary, I think that new features should only go to the master
>> branch, while only bug-fixes would be back-ported to MATH_3_X.
>> Thus everybody can have the best of both, while reducing the
>> amount of work for the developers.  Continuing in this way, and
>> we'll soon have to also "forward-port" bugs reported against the
>> 3.x series. :-/
>
> Hey, I already do that! The following one-liner is my new
> favorite:
>
>   git diff -p MATH_3_X~1 MATH_3_X | sed 's,math3,math4,g' | patch -p1
>
> Yes, it is cumbersome.

I am as busy and over-subscribed as anyone and agree it is a little
cumbersome; but I am happy to do it so users can have something
stable to work with.  Realize that they too are very busy and much
as we may like to ponder over the best way to keep refactoring our
API, they just want to solve practical problems 

Re: [math] Version mgt idea

[Gilles]

On Fri, 6 Nov 2015 10:36:51 -0700, Phil Steitz wrote:

On 11/6/15 10:31 AM, Gilles wrote:

Hi.

On Fri, 6 Nov 2015 09:17:18 -0700, 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... but even-numbered lines can include breaks -


I like the proposal to be more lax on compatibility breaking than
I ever dreamed of.  ;-)


so 4.0 and 4.1
might not be compatible.


Isn't that going to cause JAR hell?


Yes, within the even-numbered branches.  But we would repackage and
rename at each version cut as we do now.


I don't follow.
Is top-level package renaming in order: e.g.
"org.apache.commons.math4m0" for 4.0
"org.apache.commons.math4m1" for 4.1
?

This would be akin to the "experimental" package idea evoked
in an earlier incarnation of this discussion.


So the only "hell" would
be if someone deploys multiple different versions from an
even-numbered branch.  We would expect them to be less widely
deployed, so this would be less of an issue.


I don't follow either.
What issue did you intend to solve with the proposal?

My wish is that all (users and developers) can enjoy a timely
official release of the "bleeding edge"; whereas it now seems
to me that you are only talking about branch naming.
[And even-numbered ones will likely not be released because
of JAR hell.]

Or what did I miss?

Gilles



Phil


Gilles


We would always maintain both an odd and
even branch - ideally in such a way that when an even numbered line
stabilized it would add a last hurrah of breaks and move to odd.
People wanting stable APIs could just stick with the odd-numbered
lines and [math] developers wanting to experiment with things and
not worry about compatibility could do that in the even-numbered
lines.  In effect, this is sort of what we are doing now in 3.x /
4.x.

I know above violates Commons policy if we actually cut releases
from the even-numbered branches - we would have to get agreement
from the Commons PMC that this is OK or somehow label the releases
differently.  Just an idea to get us out of our current bind...

Phil



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[math] Smaller Packages / Artifacts / Dependencies

[Ole Ersoy]

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, commons-math-optimization-nlp, etc)
commons-math-simulation
commons-math-statistics
commons-math-ai (Neural Networks, ...)
etc.

Cheers,
- Ole


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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

[Bernd Eckenfels]

ello,

I came across this article:

http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/

It describes attacks against common Java applications with
pre-authentication requests using malicious Java Object serialisation.
It builds upon the work of Gabriel Lawrence (@gebl) and Chris Frohoff
(@frohoff) (presented on January 28th, 2015, “Marshalling Pickles”
given at AppSecCali)

http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles

The ysoserial tool has some sample payloads, two use
commons-collection oac.collections.functors.InvokerTransformer. * 

https://github.com/frohoff/ysoserial/tree/master/src/main/java/ysoserial/payloads

The class itself is rather handy to break out of the readObject()
chains to execute arbitrary methods.

I do'nt recall any discussion here about this
class. Is this currently handled/reported? Of course the more general
problem is using serialisation with untusted peers, and if
commons-collection fixes this, there might still be other vectors, but
still I think it would be good to do something against that "bad press"?

Gruss
Bernd

* Another payload uses org.codehaus.groovy.runtime.MethodClosure from
Groovy or some sring AutoWire Stuff.


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Version mgt idea

[Gilles]

On Fri, 6 Nov 2015 12:21:46 -0700, Phil Steitz wrote:

On 11/6/15 11:02 AM, Gilles wrote:

On Fri, 6 Nov 2015 10:36:51 -0700, Phil Steitz wrote:

On 11/6/15 10:31 AM, Gilles wrote:

Hi.

On Fri, 6 Nov 2015 09:17:18 -0700, 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... but even-numbered lines can include breaks -


I like the proposal to be more lax on compatibility breaking than
I ever dreamed of.  ;-)


so 4.0 and 4.1
might not be compatible.


Isn't that going to cause JAR hell?


Yes, within the even-numbered branches.  But we would repackage and
rename at each version cut as we do now.


I don't follow.
Is top-level package renaming in order: e.g.
"org.apache.commons.math4m0" for 4.0
"org.apache.commons.math4m1" for 4.1
?


Sorry, I was not clear.  I meant that we would do the repackaging
only at major release, so both above would be .math4




This would be akin to the "experimental" package idea evoked
in an earlier incarnation of this discussion.


So the only "hell" would
be if someone deploys multiple different versions from an
even-numbered branch.  We would expect them to be less widely
deployed, so this would be less of an issue.


I don't follow either.
What issue did you intend to solve with the proposal?


Basically, limit the compat breaks to lines "known" to contain 
breaks.


My wish is that all (users and developers) can enjoy a timely
official release of the "bleeding edge"; whereas it now seems
to me that you are only talking about branch naming.
[And even-numbered ones will likely not be released because
of JAR hell.]


That is what I was trying to support.  RERO with constant API change
means you have to release API breaks often.  That's the crux of our
problem with 4.0 now.  If we want it to have a stable API, we need
to finish stabilizing it before we release anything; otherwise we
need to follow immediately with 5, 6 etc.  What I was suggesting is
that we could just advertise the fact that the 4.x API is not
expected to be stable.  Once it stabilizes, it will become 5.x.
This has the advantage that users wanting a stable API know what to
use and we only have to support 2 lines at any given time.


I got it now.  Thanks.

Gilles


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Version mgt idea

[Gary Gregory]

>
> On Fri, 6 Nov 2015 09:17:18 -0700, 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... but even-numbered lines can include breaks -
>>
> ...

This sounds awfully complicated for my puny human brain.

It's bad enough that I have to remember how each FOSS project treats
versions numbers, but having an exception within a Commons component is
even worse. This is a non-starter for me.

Gary