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.
