On Mon, Sep 11, 2017 at 1:20 PM, Gilles <gil...@harfang.homelinux.org>
wrote:

> On Sun, 10 Sep 2017 12:35:17 -0400, Raymond DeCampo wrote:
>
>> I know I haven't been around lately, but I this exchange caught my eye.
>>
>> I was trying to figure out a way to balance the issues, first, that there
>> is resistance to creating a large number of projects spun out from CM
>>
> What I came up with is as follows:  suppose we take CM and split it up into
>> a number of modules.  Then within the project we treat each module
>> independently for the purposes of maintenance, release etc.  So that if
>> the
>> geometry module is ready to cut a new release it may do so without being
>> held up by issues in the other modules.
>>
>> So, how to accomplish this and still have CM appear to be and behave like
>> one project?  Each module would have it's own development branch.  In the
>> master branch would be a copy of the last released version of each module.
>> Development happens in the development branch.  When a module is ready to
>> release, it merges into the master branch, bumps the version and releases
>> the whole thing (i.e. all of CM).
>>
>> So, e.g. say CM 4.3.5 has versions 4.1.7 of the linear algebra module and
>> 4.2.8 of the geometry module.  The geometry module is ready to make a new
>> release, so it merges into master and bumps CM to 4.3.6 and geometry to
>> 4.2.9.  The linear algebra module stays at 4.1.7.  So CM 4.3.6 is the same
>> as 4.3.5 except for the geometry module, which is now at 4.2.9.
>>
>
> Please (re)read that thread (from 10 months ago):
>   http://markmail.org/message/2674qemtl5vvrnum
>
> Is your proposal different?


One difference is that I proposed an overarching CM version, in the same
way that, e.g. JEE X is comprised of many versions of smaller standards.
However much of the discussion in that thread still applies.


>
>
> While working this out I took a stab at splitting CM into modules.  I ran
>> into issues with the stats & distribution packages as many of the tests
>> for
>> other classes depend on them.  So there's some work there to detangle some
>> of the packages.  But I was able to split out geometry, transform,
>> optimizers, filter, diffeq and machine learning without a lot of trouble.
>> See https://github.com/RayDeCampo/commons-math/tree/modules if you are
>> interested.
>>
>
> This pretty much agrees with my observations (and analyses
> thereof), presented here several times, last installment of
> which was:
>   http://markmail.org/message/rzvh3esin3neffqs



Yes, I used your posts as a roadmap when splitting it up.

Reply via email to