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 and second, that there is a practical limit to how large a project can be maintained with the current resources.
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. 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. On Tue, Sep 5, 2017 at 8:33 AM, Emmanuel Bourg <ebo...@apache.org> wrote: > Le 4/09/2017 à 15:30, Gilles a écrit : > > > I see it as a fundamental one: Why should codes unrelated > > by scope be artificially tied together by management rules > > (such as design, supported language version, release schedule, > > etc.)?[1] > > Because they share the same general scope of being math related. The > design and the supported language version can be different for each module. > > > > Why do you "prefer" multi-module, independently of the subject > > matters being talked about? > > I already explained twice in this thread. > > > > Please comment on my suggestion to create a single maven project > > for the whole of "Commons". I'd agree that this suggestion is > > ridiculous; yet some of you do the same proposal for "everything > > math-related". > > If you want to use an absurd proposal to prove your point let me try > that game too: Please comment on my suggestion to create multiple > components out of every Java package defined in the Commons components. > > > > If you had been contributing to the math codes (plural), you > > perhaps would have understood that it creates more management > > problems than it solves.[4] > > Please use foot references for external links only, your messages are > unreadable if we have to go back and forth to understand them. > > > > Again, I have to stress on what happened that led me to propose > > a new "Commons RNG": obvious improvements to the CM code base > > were outrightly rejected based on demonstrably false statements; > > i.e. the objections were not technical but for the convenience > > of one user. > > I still think that splitting RNG into its own component was a good move. > I'm less happy with Numbers, I'd have preferred a module from a > renovated "CM5" project started from scratch as I'm suggesting now for > Geometry. > > > > Do you think that I enjoy contradicting you on these matters? > > I'm starting to think that you enjoy rhetoric, probably more than > seeking compromise unfortunately. > > > > Do they want to implement another plan? What plan? > > Here is my counter-proposal: > > 1. Refactor Commons Math as a multi-module project, bump to version 5 > 2. Create two modules: geometry and legacy > 3. Release Commons Math 5, without the legacy module > 4. Spin-off new modules from the legacy module when needed > > And I'm willing to help at least for the steps 1 and 2. > > Emmanuel Bourg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
