Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4CECECCB.8090402@free.fr>
Date: Wed, 24 Nov 2010 11:45:31 +0100
From: Luc Maisonobe <Luc.Maisonobe@free.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [math] roadmap for 2.X and 3.0 ?
References: <4CECDD32.3080603@free.fr>
 <AANLkTikaa3LtM=v0tRVW_a25S65-uPLN5KD86_GZLySr@mail.gmail.com>
In-Reply-To: <AANLkTikaa3LtM=v0tRVW_a25S65-uPLN5KD86_GZLySr@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Le 24/11/2010 11:34, sebb a �crit :
> On 24 November 2010 09:38, Luc Maisonobe <Luc.Maisonobe@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