You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Luc Maisonobe <Lu...@free.fr> on 2010/11/24 10:38:58 UTC
[math] roadmap for 2.X and 3.0 ?
Hi all,
We have cut a branch for 2.X some times ago and starting work on 3.0.
2.2 is (as far as I am concerned) both a bug fix release and a
transition release towards 3.0. The recent thread about repackaging a
set of user-related exceptions showed this point of view.
I first intended to wait until MATH-380 was at least partially covered
to release 2.2. It appears that the jacobians computation with ODE is
yet another bad design from me and add to be completely rewritten. I am
working on a new much cleaner design, but it breaks compatibility.
Therefore, I postponed MATH-380 to 3.0 and will propose this new design
for discussion to the list in the near future with the intent to put it
only in 3.0 and not in 2.2.
At the same time, working on both 2.X branch and 3.0 trunk becomes a
nightmare. I try to keep things in sync as much as possible. I
reintroduced some 3.0 exceptions in 2.X because it made sense and
allowed smooth transition, clean up javadoc when it announces in the
trunk that some class was deprecated in 2.2 when in fact nothing has
been put in the branch ...
I would very much like to have 2.X released early, preferably in
December. I also think 3.0 should be released early (perhaps during
spring) as some projects I know of would need it.
There are 10 Jira issues open for 2.2. MATH-327 and MATH-383 are about
SVD (still not robust enough it seems). I don't know if they can be
addressed now or should be postponed. I think we still need to improve
our SVD. MATH-408 and MATH-420 have been raised by Phil himself so I
probably knows if they should be solved now or not. I think MATH-402
could be fixed, as the spec pointed out by Phil say in note 358 page 532
that complex pow(c,z) could be implemented as exp(c*log(z)) and
log(0)=-inf+yi (y being 0 or pi depending on sign of 0) and exp(O+yi)=0
for finite y. The Jira comments and some threads on this list show that
much work has already been done on MATH-385, MATH-384, MATH-364,
MATH-228 (mostly on the list, not as Jira comments). I'll have a look at
MATH-414.
I also noticed we now have an increasing number of users and some
complex projects among them. So it may be time for us to follow the
general trend proposed for commons components and switch our top level
package name from org.apache.commons.math to org.apache.commons.math3
for this version. This would help people have both versions in their
classpath without names clashes. I'm sure James will be happy with this
proposal ;-)
So, what do you think ?
best regards,
Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] roadmap for 2.X and 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
> [...]
>
> I would very much like to have 2.X released early, preferably in
> December. I also think 3.0 should be released early (perhaps during
> spring) as some projects I know of would need it.
>
++1 (for both releases)
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] roadmap for 2.X and 3.0 ?
Posted by Phil Steitz <ph...@gmail.com>.
On Wed, Nov 24, 2010 at 4:38 AM, Luc Maisonobe <Lu...@free.fr>wrote:
> Hi all,
>
> We have cut a branch for 2.X some times ago and starting work on 3.0.
> 2.2 is (as far as I am concerned) both a bug fix release and a
> transition release towards 3.0. The recent thread about repackaging a
> set of user-related exceptions showed this point of view.
>
> I first intended to wait until MATH-380 was at least partially covered
> to release 2.2. It appears that the jacobians computation with ODE is
> yet another bad design from me and add to be completely rewritten. I am
> working on a new much cleaner design, but it breaks compatibility.
> Therefore, I postponed MATH-380 to 3.0 and will propose this new design
> for discussion to the list in the near future with the intent to put it
> only in 3.0 and not in 2.2.
>
+1
>
> At the same time, working on both 2.X branch and 3.0 trunk becomes a
> nightmare. I try to keep things in sync as much as possible. I
> reintroduced some 3.0 exceptions in 2.X because it made sense and
> allowed smooth transition, clean up javadoc when it announces in the
> trunk that some class was deprecated in 2.2 when in fact nothing has
> been put in the branch ...
>
+1 on trying to keep javadoc consistent - when we add "deprecated in 2.2" in
trunk we need to actually do the deprecation in the 2.x branch (preferably
in the same commit). We don't have to be perfect in comprehension here -
just consistent.
>
> I would very much like to have 2.X released early, preferably in
> December. I also think 3.0 should be released early (perhaps during
> spring) as some projects I know of would need it.
>
+1
>
> There are 10 Jira issues open for 2.2. MATH-327 and MATH-383 are about
> SVD (still not robust enough it seems). I don't know if they can be
> addressed now or should be postponed. I think we still need to improve
> our SVD.
Let's aim to patch what we can in the runup to 2.2 but not hold the release
for final resolution to both of these issues.
> MATH-408
This one needs to be fixed. Honestly, we should not have released this code
without validation tests. My bad. Patches are most welcome. I will do
this using R if we don't get any patches in the next couple of weeks.
> and MATH-420
This one is easy and I will fix it in the next couple of days.
> have been raised by Phil himself so I
> probably knows if they should be solved now or not. I think MATH-402
> could be fixed, as the spec pointed out by Phil say in note 358 page 532
> that complex pow(c,z) could be implemented as exp(c*log(z)) and
> log(0)=-inf+yi (y being 0 or pi depending on sign of 0) and exp(O+yi)=0
> for finite y.
Would appreciate others' opinions on this in the ticket. Looks to me like
our code matches the spec, so I am leaning toward INVALID; but I may be
wrong.
MATH-385, MATH-384
Pretty much done by Mikkel. Comments on tickets welcome. We should be able
to get this in.
> , MATH-364,
>
Nice enhancement and patch, but no IP clearance, so probably best to push
out to 3.0 unless someone is able / has bandwidth to clean room this and add
validation tests.
> MATH-228
Close to done by Mikkel. Review and comments welcome!
> (mostly on the list, not as Jira comments). I'll have a look at
> MATH-414.
>
So will I. Probably can effectively truncate.
>
> I also noticed we now have an increasing number of users and some
> complex projects among them. So it may be time for us to follow the
> general trend proposed for commons components and switch our top level
> package name from org.apache.commons.math to org.apache.commons.math3
> for this version. This would help people have both versions in their
> classpath without names clashes. I'm sure James will be happy with this
> proposal ;-)
>
> So, what do you think ?
>
+1 for repackaging 3.0 code and a push to get 2.2 out ASAP.
Phil
>
> best regards,
> Luc
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [math] roadmap for 2.X and 3.0 ?
Posted by James Carman <ja...@carmanconsulting.com>.
Ok, so if you guys go to a 3.0 version which breaks compatibility,
then I'd suggest you do the package/artifactId "switcheroo". Note,
this is not technically changing the name of the project. It's merely
a way to avoid "jar hell" (as has been discussed numerous times).
Yes, it will involve a bit of a migration for users, but since you're
binary incompatible, they're already having to do some migration and
find/replace the package name is a very easy fix (as a starting point
for them) for them.
On Wed, Nov 24, 2010 at 10:09 AM, Luc Maisonobe <Lu...@free.fr> wrote:
> Le 24/11/2010 15:34, James Carman a écrit :
>> If you break compatibility, then the advisable thing to do is change
>> the package name (and artifactId, etc.). Now, if we can be almost
>> certain that there would be no case that you wouldn't have a situation
>> come up where two different, incompatible versions of math would be
>> required on the classpath (you guys can't think of a situation where
>> one project might use two different libraries that use two different
>> version of math?), then I would think it would be acceptable to not
>> change the package name. I obviously find that assertion to be
>> suspect.
>
> I already know two such projects.
>
> The first one uses [math] and a lot of other libraries and packs
> everything in a big library provided to several different teams. These
> teams are not in sync and despite the project manager would probably
> very much like to have them use one version only, I'm sure it will not
> happen before the final freeze of the product. At one time, there will
> most probably be both math 2.2 and math 3.0 embedded in this single big
> library.
>
> The second project uses Orekit (which relies on [math]) and also uses
> [math] directly. Orekit does track [math] evolution closely (the ODE
> refactoring stuff is the next big change it really needs) but the top
> level project does not necessarily wants to switch to the new
> optimization stuff soon, so they may also use both versions.
>
> Luc
>
>>
>> On Wed, Nov 24, 2010 at 9:27 AM, Gilles Sadowski
>> <gi...@harfang.homelinux.org> wrote:
>>> Hi.
>>>
>>>>> [...]
>>>>>
>>>>> The name change is an option only if we can reasonably expect that
>>>>> applications would use both "math" and "math3".
>>>>
>>>> No, the sole purpose of such a change is to avoid jar hell for
>>>> applications that do not use fancy loading mechanisms like OSGi.
>>>
>>>
>>> Why, "no"?
>>> "Jar hell" is indeed what I meant: When some application has e.g.
>>> "commons-math-2.2.jar" and "commons-math-3.0.jar" in the classpath
>>> with the base package being "org.apache.commons.math" for both.
>>>
>>> A name change allows "math" (classes at vesion 2.2) and "math3" (classes at
>>> version 3.0) to coexist.
>>>
>>> However, this (implicitly) suggests that both can be used, whereas, as you
>>> say below, old releases immediately become unsupported.
>>>
>>> [And we come back to the arguments that were laid out last time the name
>>> change was proposed: namely, after "math3", there will be "math4", etc.
>>> All library projects could do that, and a version number would become
>>> useless. Since they don't, there must be drawbacks ;-).]
>>>
>>>>> But that would mean that we
>>>>> can promise to the developers of those applications, that both "math" and
>>>>> "math3" will be supported in the future. I don't think there are human
>>>>> ressources to do that (and, as you pointed out, it is not a nice and easy
>>>>> job).
>>>>
>>>> Yes. Once a release is done, we suggest people finding bug in a previous
>>>> version to first check if it is still present in the last one and we fix
>>>> it in this version. I am not aware of any real case for which we would
>>>> have published a fix for an old version.
>>>
>>> Then, a name change is not necessary. [It is even harmful from a visibility
>>> ("marketing") point-of-view.]
>>>
>>>
>>> Regards,
>>> Gilles
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] roadmap for 2.X and 3.0 ?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 24/11/2010 15:34, James Carman a écrit :
> If you break compatibility, then the advisable thing to do is change
> the package name (and artifactId, etc.). Now, if we can be almost
> certain that there would be no case that you wouldn't have a situation
> come up where two different, incompatible versions of math would be
> required on the classpath (you guys can't think of a situation where
> one project might use two different libraries that use two different
> version of math?), then I would think it would be acceptable to not
> change the package name. I obviously find that assertion to be
> suspect.
I already know two such projects.
The first one uses [math] and a lot of other libraries and packs
everything in a big library provided to several different teams. These
teams are not in sync and despite the project manager would probably
very much like to have them use one version only, I'm sure it will not
happen before the final freeze of the product. At one time, there will
most probably be both math 2.2 and math 3.0 embedded in this single big
library.
The second project uses Orekit (which relies on [math]) and also uses
[math] directly. Orekit does track [math] evolution closely (the ODE
refactoring stuff is the next big change it really needs) but the top
level project does not necessarily wants to switch to the new
optimization stuff soon, so they may also use both versions.
Luc
>
> On Wed, Nov 24, 2010 at 9:27 AM, Gilles Sadowski
> <gi...@harfang.homelinux.org> wrote:
>> Hi.
>>
>>>> [...]
>>>>
>>>> The name change is an option only if we can reasonably expect that
>>>> applications would use both "math" and "math3".
>>>
>>> No, the sole purpose of such a change is to avoid jar hell for
>>> applications that do not use fancy loading mechanisms like OSGi.
>>
>>
>> Why, "no"?
>> "Jar hell" is indeed what I meant: When some application has e.g.
>> "commons-math-2.2.jar" and "commons-math-3.0.jar" in the classpath
>> with the base package being "org.apache.commons.math" for both.
>>
>> A name change allows "math" (classes at vesion 2.2) and "math3" (classes at
>> version 3.0) to coexist.
>>
>> However, this (implicitly) suggests that both can be used, whereas, as you
>> say below, old releases immediately become unsupported.
>>
>> [And we come back to the arguments that were laid out last time the name
>> change was proposed: namely, after "math3", there will be "math4", etc.
>> All library projects could do that, and a version number would become
>> useless. Since they don't, there must be drawbacks ;-).]
>>
>>>> But that would mean that we
>>>> can promise to the developers of those applications, that both "math" and
>>>> "math3" will be supported in the future. I don't think there are human
>>>> ressources to do that (and, as you pointed out, it is not a nice and easy
>>>> job).
>>>
>>> Yes. Once a release is done, we suggest people finding bug in a previous
>>> version to first check if it is still present in the last one and we fix
>>> it in this version. I am not aware of any real case for which we would
>>> have published a fix for an old version.
>>
>> Then, a name change is not necessary. [It is even harmful from a visibility
>> ("marketing") point-of-view.]
>>
>>
>> Regards,
>> Gilles
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] roadmap for 2.X and 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> [...]
>
> As I said, the use case driving the need for the package name change is
> really beyond users' control, so I am +1 on the package name change for 3.0
>
> >
> > [1] I would be the first to have a little less work as a result of the name
> > change.
+1
Gilles
P.S. Can we do the change ASAP? Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] roadmap for 2.X and 3.0 ?
Posted by sebb <se...@gmail.com>.
On 25 November 2010 15:42, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
> Hi.
>
>> +1 on the package name change for 3.0
>
> No one seems to have voted against.
>
> Shall I assign issue
> https://issues.apache.org/jira/browse/MATH-444
> to myself and perform the change?
As mentioned previoulsy, I would leave this till just before release
to make it easier to run Clirr.
Have all the @since markers been added?
Have the release notes been updated with all the API changes?
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] roadmap for 2.X and 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
> +1 on the package name change for 3.0
No one seems to have voted against.
Shall I assign issue
https://issues.apache.org/jira/browse/MATH-444
to myself and perform the change?
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: AW: [math] roadmap for 2.X and 3.0 ?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 24/11/2010 18:44, sebb a écrit :
> On 24 November 2010 17:01, Luc Maisonobe <Lu...@free.fr> wrote:
>> Le 24/11/2010 17:19, Dietmar Wolz a écrit :
>>>
>>>
>>>> that depends on math 2.1. Orekit itself (or whatever other immediate
>>>> dependency) may not have cut a release changing its internal use to 3.0. At
>>>
>>> Is this realistic? I would expect quite early an Orekit version supporting CM
>>> 3.0.
>>
>> For Orekit, you are right, we will be 3.0 ready very early but it is a
>> somewhat ideal situation: the same people are involved in both tools.
>> Also in the example situation I presented, the problem is in fact the
>> other way round: Orekit will switch to 3.0 much earlier than the top
>> level project. This does not change the problem, though: in both cases
>> we have two libraries that need two different versions, their relative
>> ordering is irrelevant.
>>
>>> May be not a release but the actual Orekit trunk. So for your own release you
>>> would have to wait for the next Orekit release which is CM 3.0 compatible.
>>> But in the meantime you can still test your CM 3.0 compatible stuff - by using
>>> a not yet officially released Orekit version.
>>> Are there projects where such a procedure is not acceptable?
>>
>> There are operational projects that are not allowed to rely on
>> unpublished versions. The intermediate libraries may also be
>> closed-source and people may simply not want to buy new versions too
>> often. So they would have to wait for an official release of
>> commons-math, then an official release of ALL the libraries that depend
>> on commons-math, then they could start upgrading themselves. As some
>> libraries may well be stable enough to not require publishing a new
>> version, that would condemn their users to stick to commons-math 2.x for
>> a long time.
>>
>> This is one classical situation for jar hell: project A uses components
>> B1 and B2 and both components use a low level C component. A bug is
>> discovered in C and it is a major one for B1. Then a new version of C is
>> published, followed by a new version of B1 that depends on it. However
>> B2 is not affected by this bug and is a stable component: it does not
>> update its use of C and still rely on the old version with the bug.
>> Project A is in jar hell.
>
> It's only in jar hell if C2 is not binary compatible with C1 (and then
> only if B2 uses the part of C1 that changed in C2)
Yes, sorry, the example was not complete.
thanks for the clarification
Luc
>
> Otherwise, surely just replace C with Cv2 and both B1 and B2 are happy?
>
> If C1 and C2 have the same Maven gid:aid combination, only C2 willl be
> put on the classpath.
>
>> The situation is worse if B2 is not an
>> open-source project, as project A really cannot make the change by itself.
>>
>> Luc
>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: AW: [math] roadmap for 2.X and 3.0 ?
Posted by sebb <se...@gmail.com>.
On 24 November 2010 17:01, Luc Maisonobe <Lu...@free.fr> wrote:
> Le 24/11/2010 17:19, Dietmar Wolz a écrit :
>>
>>
>>> that depends on math 2.1. Orekit itself (or whatever other immediate
>>> dependency) may not have cut a release changing its internal use to 3.0. At
>>
>> Is this realistic? I would expect quite early an Orekit version supporting CM
>> 3.0.
>
> For Orekit, you are right, we will be 3.0 ready very early but it is a
> somewhat ideal situation: the same people are involved in both tools.
> Also in the example situation I presented, the problem is in fact the
> other way round: Orekit will switch to 3.0 much earlier than the top
> level project. This does not change the problem, though: in both cases
> we have two libraries that need two different versions, their relative
> ordering is irrelevant.
>
>> May be not a release but the actual Orekit trunk. So for your own release you
>> would have to wait for the next Orekit release which is CM 3.0 compatible.
>> But in the meantime you can still test your CM 3.0 compatible stuff - by using
>> a not yet officially released Orekit version.
>> Are there projects where such a procedure is not acceptable?
>
> There are operational projects that are not allowed to rely on
> unpublished versions. The intermediate libraries may also be
> closed-source and people may simply not want to buy new versions too
> often. So they would have to wait for an official release of
> commons-math, then an official release of ALL the libraries that depend
> on commons-math, then they could start upgrading themselves. As some
> libraries may well be stable enough to not require publishing a new
> version, that would condemn their users to stick to commons-math 2.x for
> a long time.
>
> This is one classical situation for jar hell: project A uses components
> B1 and B2 and both components use a low level C component. A bug is
> discovered in C and it is a major one for B1. Then a new version of C is
> published, followed by a new version of B1 that depends on it. However
> B2 is not affected by this bug and is a stable component: it does not
> update its use of C and still rely on the old version with the bug.
> Project A is in jar hell.
It's only in jar hell if C2 is not binary compatible with C1 (and then
only if B2 uses the part of C1 that changed in C2)
Otherwise, surely just replace C with Cv2 and both B1 and B2 are happy?
If C1 and C2 have the same Maven gid:aid combination, only C2 willl be
put on the classpath.
> The situation is worse if B2 is not an
> open-source project, as project A really cannot make the change by itself.
>
> Luc
>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: AW: [math] roadmap for 2.X and 3.0 ?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 24/11/2010 17:19, Dietmar Wolz a écrit :
>
>
>> that depends on math 2.1. Orekit itself (or whatever other immediate
>> dependency) may not have cut a release changing its internal use to 3.0. At
>
> Is this realistic? I would expect quite early an Orekit version supporting CM
> 3.0.
For Orekit, you are right, we will be 3.0 ready very early but it is a
somewhat ideal situation: the same people are involved in both tools.
Also in the example situation I presented, the problem is in fact the
other way round: Orekit will switch to 3.0 much earlier than the top
level project. This does not change the problem, though: in both cases
we have two libraries that need two different versions, their relative
ordering is irrelevant.
> May be not a release but the actual Orekit trunk. So for your own release you
> would have to wait for the next Orekit release which is CM 3.0 compatible.
> But in the meantime you can still test your CM 3.0 compatible stuff - by using
> a not yet officially released Orekit version.
> Are there projects where such a procedure is not acceptable?
There are operational projects that are not allowed to rely on
unpublished versions. The intermediate libraries may also be
closed-source and people may simply not want to buy new versions too
often. So they would have to wait for an official release of
commons-math, then an official release of ALL the libraries that depend
on commons-math, then they could start upgrading themselves. As some
libraries may well be stable enough to not require publishing a new
version, that would condemn their users to stick to commons-math 2.x for
a long time.
This is one classical situation for jar hell: project A uses components
B1 and B2 and both components use a low level C component. A bug is
discovered in C and it is a major one for B1. Then a new version of C is
published, followed by a new version of B1 that depends on it. However
B2 is not affected by this bug and is a stable component: it does not
update its use of C and still rely on the old version with the bug.
Project A is in jar hell. The situation is worse if B2 is not an
open-source project, as project A really cannot make the change by itself.
Luc
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
AW: [math] roadmap for 2.X and 3.0 ?
Posted by Dietmar Wolz <dr...@yahoo.de>.
>that depends on math 2.1. Orekit itself (or whatever other immediate
>dependency) may not have cut a release changing its internal use to 3.0. At
Is this realistic? I would expect quite early an Orekit version supporting CM
3.0.
May be not a release but the actual Orekit trunk. So for your own release you
would have to wait for the next Orekit release which is CM 3.0 compatible.
But in the meantime you can still test your CM 3.0 compatible stuff - by using
a not yet officially released Orekit version.
Are there projects where such a procedure is not acceptable?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] roadmap for 2.X and 3.0 ?
Posted by Phil Steitz <ph...@gmail.com>.
On Wed, Nov 24, 2010 at 10:34 AM, Gilles Sadowski <
gilles@harfang.homelinux.org> wrote:
> Hello.
>
> > If you break compatibility, then the advisable thing to do is change
> > the package name (and artifactId, etc.). Now, if we can be almost
> > certain that there would be no case that you wouldn't have a situation
> > come up where two different, incompatible versions of math would be
> > required on the classpath (you guys can't think of a situation where
> > one project might use two different libraries that use two different
> > version of math?),
>
> Wouldn't it mean that at least one of the two libraries is not an active
> project? Otherwise I'd think they would benefit from upgrading.
>
Not necessarily. The Orekit example that Luc gave is a good one. A
project could use [math] directly and be very actively maintained and
needing the 3.0 features / fixes, but depend on an earlier version of Orekit
that depends on math 2.1. Orekit itself (or whatever other immediate
dependency) may not have cut a release changing its internal use to 3.0. At
that point, the project using both [math] directly and Orekit needs to have
both versions available. Since dependency on the 2.1 code is encapsulated
in Orekit, there is no need for the [math] versions to be compatible for the
app to work.
>
> Another aspect is that, by making it possible, we would encourage "lazy"
> users to not upgrade, and would thus loose them as "testers" of the new
> releases.
>
> It's nice to help users[1] but we should not forget that we can be
> confident
> in the code only if it is largely used. Bugs in the "linear" package went
> unnoticed until a real-world code stressed it.
> So, I'm not sure that, at this point, we can afford "lazy" users ;-) [I'm
> playing the devil's advocate here.]
>
As I said, the use case driving the need for the package name change is
really beyond users' control, so I am +1 on the package name change for 3.0
Phil
>
> > [...]
>
>
> Gilles
>
> [1] I would be the first to have a little less work as a result of the name
> change.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [math] roadmap for 2.X and 3.0 ?
Posted by James Carman <ja...@carmanconsulting.com>.
On Wed, Nov 24, 2010 at 10:34 AM, Gilles Sadowski
<gi...@harfang.homelinux.org> wrote:
>
> Wouldn't it mean that at least one of the two libraries is not an active
> project? Otherwise I'd think they would benefit from upgrading.
>
So what if it isn't? If the library works for what you need it to do
and it relies on an older version of commons math, then why stop using
it? Also, if you don't have control over the third-party library,
then you can't force them to upgrade (as they may have users other
than you).
> Another aspect is that, by making it possible, we would encourage "lazy"
> users to not upgrade, and would thus loose them as "testers" of the new
> releases.
>
Well, I wouldn't exactly call them "lazy", but again if an older
version of commons math works for what they need to do and they've got
a production system using it, then why should they try to upgrade if
they don't need any of the newer features? Why introduce a new
variable into a perfectly-running system? Now, if they wish to use
new features, then they will no doubt upgrade. The situation we're
trying to avoid is where our users get upset because we've set them up
for failure by releasing two binary incompatible versions and they
have code (direct or indirect) that depends on both version. When
that happens, they might look to other solutions/libraries. Do you
think they'll be testing your new features then?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] roadmap for 2.X and 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
> If you break compatibility, then the advisable thing to do is change
> the package name (and artifactId, etc.). Now, if we can be almost
> certain that there would be no case that you wouldn't have a situation
> come up where two different, incompatible versions of math would be
> required on the classpath (you guys can't think of a situation where
> one project might use two different libraries that use two different
> version of math?),
Wouldn't it mean that at least one of the two libraries is not an active
project? Otherwise I'd think they would benefit from upgrading.
Another aspect is that, by making it possible, we would encourage "lazy"
users to not upgrade, and would thus loose them as "testers" of the new
releases.
It's nice to help users[1] but we should not forget that we can be confident
in the code only if it is largely used. Bugs in the "linear" package went
unnoticed until a real-world code stressed it.
So, I'm not sure that, at this point, we can afford "lazy" users ;-) [I'm
playing the devil's advocate here.]
> [...]
Gilles
[1] I would be the first to have a little less work as a result of the name
change.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] roadmap for 2.X and 3.0 ?
Posted by James Carman <ja...@carmanconsulting.com>.
If you break compatibility, then the advisable thing to do is change
the package name (and artifactId, etc.). Now, if we can be almost
certain that there would be no case that you wouldn't have a situation
come up where two different, incompatible versions of math would be
required on the classpath (you guys can't think of a situation where
one project might use two different libraries that use two different
version of math?), then I would think it would be acceptable to not
change the package name. I obviously find that assertion to be
suspect.
On Wed, Nov 24, 2010 at 9:27 AM, Gilles Sadowski
<gi...@harfang.homelinux.org> wrote:
> Hi.
>
>> > [...]
>> >
>> > The name change is an option only if we can reasonably expect that
>> > applications would use both "math" and "math3".
>>
>> No, the sole purpose of such a change is to avoid jar hell for
>> applications that do not use fancy loading mechanisms like OSGi.
>
>
> Why, "no"?
> "Jar hell" is indeed what I meant: When some application has e.g.
> "commons-math-2.2.jar" and "commons-math-3.0.jar" in the classpath
> with the base package being "org.apache.commons.math" for both.
>
> A name change allows "math" (classes at vesion 2.2) and "math3" (classes at
> version 3.0) to coexist.
>
> However, this (implicitly) suggests that both can be used, whereas, as you
> say below, old releases immediately become unsupported.
>
> [And we come back to the arguments that were laid out last time the name
> change was proposed: namely, after "math3", there will be "math4", etc.
> All library projects could do that, and a version number would become
> useless. Since they don't, there must be drawbacks ;-).]
>
>> > But that would mean that we
>> > can promise to the developers of those applications, that both "math" and
>> > "math3" will be supported in the future. I don't think there are human
>> > ressources to do that (and, as you pointed out, it is not a nice and easy
>> > job).
>>
>> Yes. Once a release is done, we suggest people finding bug in a previous
>> version to first check if it is still present in the last one and we fix
>> it in this version. I am not aware of any real case for which we would
>> have published a fix for an old version.
>
> Then, a name change is not necessary. [It is even harmful from a visibility
> ("marketing") point-of-view.]
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] roadmap for 2.X and 3.0 ?
Posted by James Carman <ja...@carmanconsulting.com>.
On Wed, Nov 24, 2010 at 11:09 AM, Dietmar Wolz <dr...@yahoo.de> wrote:
>
> The question is: Are there projects using CM where the transition time is
> large enough to justify the usage of two different versions of CM at
> the same time? I am usually working in an OSGI-context where in principal
> such situations are supported. But we never use it for direct project
> dependencies
> but only for indirect ones - for instance if we depend on two
> third party libraries which depend on two different versions of a third one.
> And if I have to support a complex dependency graph - why not using OSGI?
>
Because not all of us have the luxury (or the desire) to use OSGi.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: AW: [math] roadmap for 2.X and 3.0 ?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 24/11/2010 17:09, Dietmar Wolz a écrit :
>
>
>> The name change is not for maintaining several versions in parallel. It
>> is to allow projects to have parts depending on the old (unmaintained)
>> version and new (maintained) version to compile and let them go back in
>> sync progressively. It is exactly the same process than the change in
>> 2.2 for the user exceptions: we know there WILL be a transition period
>> for some projects and we help them during this transition.
>
> Today I did the version update from 2.1 to the current trunk for my GTOC5
> trajectory
> optimization framework which uses CM and Orekit. There were
> a lot of changes necessary but I managed to do them in about two hours.
>
> The question is: Are there projects using CM where the transition time is
> large enough to justify the usage of two different versions of CM at
It's not always a matter of time. Change may be impossible due to either
project management rules, long certification processes before accepting
a new version of a subcomponent, or simply because source code is not
available.
> the same time? I am usually working in an OSGI-context where in principal
> such situations are supported. But we never use it for direct project
> dependencies
> but only for indirect ones - for instance if we depend on two
> third party libraries which depend on two different versions of a third one.
> And if I have to support a complex dependency graph - why not using OSGI?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
AW: [math] roadmap for 2.X and 3.0 ?
Posted by Dietmar Wolz <dr...@yahoo.de>.
>The name change is not for maintaining several versions in parallel. It
>is to allow projects to have parts depending on the old (unmaintained)
>version and new (maintained) version to compile and let them go back in
>sync progressively. It is exactly the same process than the change in
>2.2 for the user exceptions: we know there WILL be a transition period
>for some projects and we help them during this transition.
Today I did the version update from 2.1 to the current trunk for my GTOC5
trajectory
optimization framework which uses CM and Orekit. There were
a lot of changes necessary but I managed to do them in about two hours.
The question is: Are there projects using CM where the transition time is
large enough to justify the usage of two different versions of CM at
the same time? I am usually working in an OSGI-context where in principal
such situations are supported. But we never use it for direct project
dependencies
but only for indirect ones - for instance if we depend on two
third party libraries which depend on two different versions of a third one.
And if I have to support a complex dependency graph - why not using OSGI?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] roadmap for 2.X and 3.0 ?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 24/11/2010 15:27, Gilles Sadowski a écrit :
> Hi.
>
>>> [...]
>>>
>>> The name change is an option only if we can reasonably expect that
>>> applications would use both "math" and "math3".
>>
>> No, the sole purpose of such a change is to avoid jar hell for
>> applications that do not use fancy loading mechanisms like OSGi.
>
>
> Why, "no"?
> "Jar hell" is indeed what I meant: When some application has e.g.
> "commons-math-2.2.jar" and "commons-math-3.0.jar" in the classpath
> with the base package being "org.apache.commons.math" for both.
I put my sentence at the wrong place, sorry. The no was an answer to the
following paragraph, i.e. "we can promise to the developers of those
applications, that both "math" and "math3" will be supported in the
future". I meant: no, we don't promise that. For the paragraph above,
i.e. "we can reasonably expect that applications would use both "math"
and "math3"", I would say yes, we expect it.
>
> A name change allows "math" (classes at vesion 2.2) and "math3" (classes at
> version 3.0) to coexist.
>
> However, this (implicitly) suggests that both can be used, whereas, as you
> say below, old releases immediately become unsupported.
>
> [And we come back to the arguments that were laid out last time the name
> change was proposed: namely, after "math3", there will be "math4", etc.
> All library projects could do that, and a version number would become
> useless. Since they don't, there must be drawbacks ;-).]
Yes, but the change since last time is that now [math] as more users and
with bigger expectations. Another change is that many other commons
components have adopted the policy of changing package name.
>
>>> But that would mean that we
>>> can promise to the developers of those applications, that both "math" and
>>> "math3" will be supported in the future. I don't think there are human
>>> ressources to do that (and, as you pointed out, it is not a nice and easy
>>> job).
>>
>> Yes. Once a release is done, we suggest people finding bug in a previous
>> version to first check if it is still present in the last one and we fix
>> it in this version. I am not aware of any real case for which we would
>> have published a fix for an old version.
>
> Then, a name change is not necessary. [It is even harmful from a visibility
> ("marketing") point-of-view.]
The name change is not for maintaining several versions in parallel. It
is to allow projects to have parts depending on the old (unmaintained)
version and new (maintained) version to compile and let them go back in
sync progressively. It is exactly the same process than the change in
2.2 for the user exceptions: we know there WILL be a transition period
for some projects and we help them during this transition.
Luc
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] roadmap for 2.X and 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
> > [...]
> >
> > The name change is an option only if we can reasonably expect that
> > applications would use both "math" and "math3".
>
> No, the sole purpose of such a change is to avoid jar hell for
> applications that do not use fancy loading mechanisms like OSGi.
Why, "no"?
"Jar hell" is indeed what I meant: When some application has e.g.
"commons-math-2.2.jar" and "commons-math-3.0.jar" in the classpath
with the base package being "org.apache.commons.math" for both.
A name change allows "math" (classes at vesion 2.2) and "math3" (classes at
version 3.0) to coexist.
However, this (implicitly) suggests that both can be used, whereas, as you
say below, old releases immediately become unsupported.
[And we come back to the arguments that were laid out last time the name
change was proposed: namely, after "math3", there will be "math4", etc.
All library projects could do that, and a version number would become
useless. Since they don't, there must be drawbacks ;-).]
> > But that would mean that we
> > can promise to the developers of those applications, that both "math" and
> > "math3" will be supported in the future. I don't think there are human
> > ressources to do that (and, as you pointed out, it is not a nice and easy
> > job).
>
> Yes. Once a release is done, we suggest people finding bug in a previous
> version to first check if it is still present in the last one and we fix
> it in this version. I am not aware of any real case for which we would
> have published a fix for an old version.
Then, a name change is not necessary. [It is even harmful from a visibility
("marketing") point-of-view.]
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] roadmap for 2.X and 3.0 ?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 24/11/2010 13:10, Gilles Sadowski a écrit :
> Hi Luc.
>
>> [...]
>>>>
>>>> I also noticed we now have an increasing number of users and some
>>>> complex projects among them. So it may be time for us to follow the
>>>> general trend proposed for commons components and switch our top level
>>>> package name from org.apache.commons.math to org.apache.commons.math3
>>>> for this version. This would help people have both versions in their
>>>> classpath without names clashes. I'm sure James will be happy with this
>>>> proposal ;-)
>>>
>>> If the API is incompatible, changing the package name is essential IF
>>> there are likely to be multiple dependencies on Math.
>>
>> Yes. There is one big research project split into many components
>> developed by different unsynchronized teams throughout the world.
>> Commons-math is one of their dependencies.
>>
>> I'm pretty sure some components are already using 3.0 (well, they have
>> committers here ...) and also some other teams are still stuck with 2.1.
>> With different package names, it will probably help them transition at
>> their own pace before everyone is in sync again (if it ever happens ...)
>
> Thank you for trying to help with this.
> However, although the name change would be the simplest solution for the
> problem I encounter right now, it should not be done lightly (i.e. only
> because of that temporary situation).
>
> The name change is an option only if we can reasonably expect that
> applications would use both "math" and "math3".
No, the sole purpose of such a change is to avoid jar hell for
applications that do not use fancy loading mechanisms like OSGi.
> But that would mean that we
> can promise to the developers of those applications, that both "math" and
> "math3" will be supported in the future. I don't think there are human
> ressources to do that (and, as you pointed out, it is not a nice and easy
> job).
Yes. Once a release is done, we suggest people finding bug in a previous
version to first check if it is still present in the last one and we fix
it in this version. I am not aware of any real case for which we would
have published a fix for an old version.
regards,
Luc
>
> The mentioned project is expected to use a single version of Commons-Math,
> the supported one, at least until there is a code freeze. So after assessing
> the impact of upgrading to 3.0, the whole project will probably probably do
> so, and be in sync again.
>
> Hence, I think that it is best not to fork Commons-Math at this point.
>
>
> Best regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] roadmap for 2.X and 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi Luc.
> [...]
> >>
> >> I also noticed we now have an increasing number of users and some
> >> complex projects among them. So it may be time for us to follow the
> >> general trend proposed for commons components and switch our top level
> >> package name from org.apache.commons.math to org.apache.commons.math3
> >> for this version. This would help people have both versions in their
> >> classpath without names clashes. I'm sure James will be happy with this
> >> proposal ;-)
> >
> > If the API is incompatible, changing the package name is essential IF
> > there are likely to be multiple dependencies on Math.
>
> Yes. There is one big research project split into many components
> developed by different unsynchronized teams throughout the world.
> Commons-math is one of their dependencies.
>
> I'm pretty sure some components are already using 3.0 (well, they have
> committers here ...) and also some other teams are still stuck with 2.1.
> With different package names, it will probably help them transition at
> their own pace before everyone is in sync again (if it ever happens ...)
Thank you for trying to help with this.
However, although the name change would be the simplest solution for the
problem I encounter right now, it should not be done lightly (i.e. only
because of that temporary situation).
The name change is an option only if we can reasonably expect that
applications would use both "math" and "math3". But that would mean that we
can promise to the developers of those applications, that both "math" and
"math3" will be supported in the future. I don't think there are human
ressources to do that (and, as you pointed out, it is not a nice and easy
job).
The mentioned project is expected to use a single version of Commons-Math,
the supported one, at least until there is a code freeze. So after assessing
the impact of upgrading to 3.0, the whole project will probably probably do
so, and be in sync again.
Hence, I think that it is best not to fork Commons-Math at this point.
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] roadmap for 2.X and 3.0 ?
Posted by sebb <se...@gmail.com>.
On 24 November 2010 10:45, Luc Maisonobe <Lu...@free.fr> wrote:
> Le 24/11/2010 11:34, sebb a écrit :
>> On 24 November 2010 09:38, Luc Maisonobe <Lu...@free.fr> wrote:
>>> Hi all,
>>>
>>> We have cut a branch for 2.X some times ago and starting work on 3.0.
>>> 2.2 is (as far as I am concerned) both a bug fix release and a
>>> transition release towards 3.0. The recent thread about repackaging a
>>> set of user-related exceptions showed this point of view.
>>>
>>> I first intended to wait until MATH-380 was at least partially covered
>>> to release 2.2. It appears that the jacobians computation with ODE is
>>> yet another bad design from me and add to be completely rewritten. I am
>>> working on a new much cleaner design, but it breaks compatibility.
>>> Therefore, I postponed MATH-380 to 3.0 and will propose this new design
>>> for discussion to the list in the near future with the intent to put it
>>> only in 3.0 and not in 2.2.
>>>
>>> At the same time, working on both 2.X branch and 3.0 trunk becomes a
>>> nightmare. I try to keep things in sync as much as possible. I
>>> reintroduced some 3.0 exceptions in 2.X because it made sense and
>>> allowed smooth transition, clean up javadoc when it announces in the
>>> trunk that some class was deprecated in 2.2 when in fact nothing has
>>> been put in the branch ...
>>>
>>> I would very much like to have 2.X released early, preferably in
>>> December. I also think 3.0 should be released early (perhaps during
>>> spring) as some projects I know of would need it.
>>>
>>> There are 10 Jira issues open for 2.2. MATH-327 and MATH-383 are about
>>> SVD (still not robust enough it seems). I don't know if they can be
>>> addressed now or should be postponed. I think we still need to improve
>>> our SVD. MATH-408 and MATH-420 have been raised by Phil himself so I
>>> probably knows if they should be solved now or not. I think MATH-402
>>> could be fixed, as the spec pointed out by Phil say in note 358 page 532
>>> that complex pow(c,z) could be implemented as exp(c*log(z)) and
>>> log(0)=-inf+yi (y being 0 or pi depending on sign of 0) and exp(O+yi)=0
>>> for finite y. The Jira comments and some threads on this list show that
>>> much work has already been done on MATH-385, MATH-384, MATH-364,
>>> MATH-228 (mostly on the list, not as Jira comments). I'll have a look at
>>> MATH-414.
>>>
>>> I also noticed we now have an increasing number of users and some
>>> complex projects among them. So it may be time for us to follow the
>>> general trend proposed for commons components and switch our top level
>>> package name from org.apache.commons.math to org.apache.commons.math3
>>> for this version. This would help people have both versions in their
>>> classpath without names clashes. I'm sure James will be happy with this
>>> proposal ;-)
>>
>> If the API is incompatible, changing the package name is essential IF
>> there are likely to be multiple dependencies on Math.
>
> Yes. There is one big research project split into many components
> developed by different unsynchronized teams throughout the world.
> Commons-math is one of their dependencies.
>
> I'm pretty sure some components are already using 3.0 (well, they have
> committers here ...) and also some other teams are still stuck with 2.1.
> With different package names, it will probably help them transition at
> their own pace before everyone is in sync again (if it ever happens ...)
>
>>
>> Note that Clirr does not have an option to treat different package
>> names as being the same code line (AFAIK).
>>
>> So consider changing the package names just before release to make it
>> easier to run Clirr in the meantime.
>
> Thanks for the hint. As we already know we have introduced
> incompatibilities, is a Clirr report still useful ?
>
Yes - it can be used to know where to add the @since markers.
It would also be useful when documenting which APIs have changed.
Updating user code is generally going to involve more than just
changing the package name and recompiling.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] roadmap for 2.X and 3.0 ?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 24/11/2010 11:34, sebb a écrit :
> On 24 November 2010 09:38, Luc Maisonobe <Lu...@free.fr> wrote:
>> Hi all,
>>
>> We have cut a branch for 2.X some times ago and starting work on 3.0.
>> 2.2 is (as far as I am concerned) both a bug fix release and a
>> transition release towards 3.0. The recent thread about repackaging a
>> set of user-related exceptions showed this point of view.
>>
>> I first intended to wait until MATH-380 was at least partially covered
>> to release 2.2. It appears that the jacobians computation with ODE is
>> yet another bad design from me and add to be completely rewritten. I am
>> working on a new much cleaner design, but it breaks compatibility.
>> Therefore, I postponed MATH-380 to 3.0 and will propose this new design
>> for discussion to the list in the near future with the intent to put it
>> only in 3.0 and not in 2.2.
>>
>> At the same time, working on both 2.X branch and 3.0 trunk becomes a
>> nightmare. I try to keep things in sync as much as possible. I
>> reintroduced some 3.0 exceptions in 2.X because it made sense and
>> allowed smooth transition, clean up javadoc when it announces in the
>> trunk that some class was deprecated in 2.2 when in fact nothing has
>> been put in the branch ...
>>
>> I would very much like to have 2.X released early, preferably in
>> December. I also think 3.0 should be released early (perhaps during
>> spring) as some projects I know of would need it.
>>
>> There are 10 Jira issues open for 2.2. MATH-327 and MATH-383 are about
>> SVD (still not robust enough it seems). I don't know if they can be
>> addressed now or should be postponed. I think we still need to improve
>> our SVD. MATH-408 and MATH-420 have been raised by Phil himself so I
>> probably knows if they should be solved now or not. I think MATH-402
>> could be fixed, as the spec pointed out by Phil say in note 358 page 532
>> that complex pow(c,z) could be implemented as exp(c*log(z)) and
>> log(0)=-inf+yi (y being 0 or pi depending on sign of 0) and exp(O+yi)=0
>> for finite y. The Jira comments and some threads on this list show that
>> much work has already been done on MATH-385, MATH-384, MATH-364,
>> MATH-228 (mostly on the list, not as Jira comments). I'll have a look at
>> MATH-414.
>>
>> I also noticed we now have an increasing number of users and some
>> complex projects among them. So it may be time for us to follow the
>> general trend proposed for commons components and switch our top level
>> package name from org.apache.commons.math to org.apache.commons.math3
>> for this version. This would help people have both versions in their
>> classpath without names clashes. I'm sure James will be happy with this
>> proposal ;-)
>
> If the API is incompatible, changing the package name is essential IF
> there are likely to be multiple dependencies on Math.
Yes. There is one big research project split into many components
developed by different unsynchronized teams throughout the world.
Commons-math is one of their dependencies.
I'm pretty sure some components are already using 3.0 (well, they have
committers here ...) and also some other teams are still stuck with 2.1.
With different package names, it will probably help them transition at
their own pace before everyone is in sync again (if it ever happens ...)
>
> Note that Clirr does not have an option to treat different package
> names as being the same code line (AFAIK).
>
> So consider changing the package names just before release to make it
> easier to run Clirr in the meantime.
Thanks for the hint. As we already know we have introduced
incompatibilities, is a Clirr report still useful ?
>
> Alternatively, it is possible to create a POM which uses Maven Shade
> to convert math <=> math3 and then runs Clirr - see for example
> https://issues.apache.org/jira/browse/VFS-344. This is a bit messy
> however.
I'll have a look at this, thanks.
regards,
Luc
>
>> So, what do you think ?
>>
>> best regards,
>> Luc
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] roadmap for 2.X and 3.0 ?
Posted by sebb <se...@gmail.com>.
On 24 November 2010 09:38, Luc Maisonobe <Lu...@free.fr> wrote:
> Hi all,
>
> We have cut a branch for 2.X some times ago and starting work on 3.0.
> 2.2 is (as far as I am concerned) both a bug fix release and a
> transition release towards 3.0. The recent thread about repackaging a
> set of user-related exceptions showed this point of view.
>
> I first intended to wait until MATH-380 was at least partially covered
> to release 2.2. It appears that the jacobians computation with ODE is
> yet another bad design from me and add to be completely rewritten. I am
> working on a new much cleaner design, but it breaks compatibility.
> Therefore, I postponed MATH-380 to 3.0 and will propose this new design
> for discussion to the list in the near future with the intent to put it
> only in 3.0 and not in 2.2.
>
> At the same time, working on both 2.X branch and 3.0 trunk becomes a
> nightmare. I try to keep things in sync as much as possible. I
> reintroduced some 3.0 exceptions in 2.X because it made sense and
> allowed smooth transition, clean up javadoc when it announces in the
> trunk that some class was deprecated in 2.2 when in fact nothing has
> been put in the branch ...
>
> I would very much like to have 2.X released early, preferably in
> December. I also think 3.0 should be released early (perhaps during
> spring) as some projects I know of would need it.
>
> There are 10 Jira issues open for 2.2. MATH-327 and MATH-383 are about
> SVD (still not robust enough it seems). I don't know if they can be
> addressed now or should be postponed. I think we still need to improve
> our SVD. MATH-408 and MATH-420 have been raised by Phil himself so I
> probably knows if they should be solved now or not. I think MATH-402
> could be fixed, as the spec pointed out by Phil say in note 358 page 532
> that complex pow(c,z) could be implemented as exp(c*log(z)) and
> log(0)=-inf+yi (y being 0 or pi depending on sign of 0) and exp(O+yi)=0
> for finite y. The Jira comments and some threads on this list show that
> much work has already been done on MATH-385, MATH-384, MATH-364,
> MATH-228 (mostly on the list, not as Jira comments). I'll have a look at
> MATH-414.
>
> I also noticed we now have an increasing number of users and some
> complex projects among them. So it may be time for us to follow the
> general trend proposed for commons components and switch our top level
> package name from org.apache.commons.math to org.apache.commons.math3
> for this version. This would help people have both versions in their
> classpath without names clashes. I'm sure James will be happy with this
> proposal ;-)
If the API is incompatible, changing the package name is essential IF
there are likely to be multiple dependencies on Math.
Note that Clirr does not have an option to treat different package
names as being the same code line (AFAIK).
So consider changing the package names just before release to make it
easier to run Clirr in the meantime.
Alternatively, it is possible to create a POM which uses Maven Shade
to convert math <=> math3 and then runs Clirr - see for example
https://issues.apache.org/jira/browse/VFS-344. This is a bit messy
however.
> So, what do you think ?
>
> best regards,
> Luc
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org