Rob Tompkins wrote:
>> On Sep 18, 2016, at 7:22 AM, Gilles <gil...@harfang.homelinux.org> wrote:
>> On Sat, 17 Sep 2016 16:07:41 +0200, Jörg Schaible wrote:
>>> Hi Rob,
>>> Rob Tompkins wrote:
>>>> Given that the long term goals of commons-math are fairly uncertain, I
>>>> would like to attempt working with some short term goals. The hope here
>>>> is to think about questions along the lines of: "what can be done
>>>> today/this week/this month,” with the goal aiming at chipping away at
>>>> what I’ll call, for lack of a better term, technical debt. I have a
>>>> couple of thoughts and am curious to see what folks generally think
>>>> here. Here are some ideas that immediately come to mind:
>>>> Items achievable in a few hours:
>>>> Move to the develop branch to the master branch.
>>>> Get travis-ci/coveralls working for pull requests.
> Given the lack of comments here, that feels like a "go for it.” But, I am
> curious what the code in “master” represents? I ask because it seems that
> it’s drifted considerably from the release of 3.6.1.
> If I do go down this road, I probably would keep the current master branch
> around for a while labeled as “master-old-<dateOfChange>” (or something
> along those lines).
Current master is a dead end. We may actually move master to a 4.x branch
and move 3.x back to master, since we we will have for the time being no
further development in Math4 that justifies a break of API.
>>>> Items achievable in a few days:
>>>> Deprecation of the packages that duplicate functionality with
>>> +1 ... normally. However, IIRC correctly, Gilles once said that all the
>>> RNG stuff was never part of a release.
>> The package
>> was created in the development branch (released CM code was from
>> the "MATH_3_X" branch) intended for work towards v4.0 (which
>> started in early 2015, by removing long deprecated codes).
>> It was a complete rewrite (with fixes, extensions, additions, and
>> removals) of code from
>> which has existed for a long time, and was named
>> in branch MATH_3_X
>> IIUC, Rob means to deprecate, in branch "MATH_3_X", codes in
>> that could be replaced by equivalent functionality defined
>> in Commons RNG.
>> A minor release of CM3 would warn users about the changes to
>> If they use the functionality from
>> in their own codes, they will already be able to upgrade
>> (to Commons RNG).
>> But if they use CM3 generators as arguments in calls to CM3,
>> then no replacements will be available, as only (unreleased)
>> CM4 can be (and has been) upgraded to depend on Commons RNG.
> This would precisely be the idea. If we are intent on modularization, then
> we should slim down the commons-math library such that it contains no
> duplications from other commons components.
+1, that's IMHO the best "upgrade" path for existing Math users.
> Lastly given those ideas, does anyone else have any ideas for what we can
> do right now on commons-math?
Well, there are a bunch of Gilles' ideas left ;-)
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org