On Tue, 2 Feb 2016 18:52:24 -0800, Gary Gregory wrote:
On Tue, Feb 2, 2016 at 6:24 PM, Gilles <gil...@harfang.homelinux.org>
wrote:
On Wed, 3 Feb 2016 12:11:24 +1100, Peter Ansell wrote:
On 3 February 2016 at 11:30, Patrick Meyer <meyer...@gmail.com>
wrote:
The Apache commons math library already has a reputation and is
well
kvown.
Any name that does not involve the words Apache and math will
require a
lot
of rebranding or years of explaining to people that the TLP named
X is
really just the library formerly known as commons math. Removing
"commons"
from the name is a good way to signal the maturity of the math
library
while staying true to its Apache origin. That's why I like Apache
math.
I don't think that outside of the Apache developer community that
the
"Commons" reference is taken to mean immaturity. If anything, it is
taken to mean something that is stable and fairly slow to evolve
and
hence can be reused fairly broadly (per the tight scopes of each of
the modules).
Indeed.
And if establishing is going to serve anything, it is IMHO certainly
not to be stuck with an a priori reputation of "being stable and
fairly
slow to evolve".
Commons Math has been steadily growing, with less and less
consideration
for evolving with the language which it uses. IMO, that means, among
other
things, less and less hope to attract new contributors.
Being a TLP is by itself not going to change that.
If anything, the new project should mean a radical departure of
being
stable wrt the latest release.
For users that don't care for new features and are happy with CM
3.6,
no problem; until they find a bug. What happens then should be
discussed
as soon as possible, as the default policy has been to support only
the
latest release.
To change that, more people are needed to maintain legacy code while
not hindering development, including major refactoring to modernize
the code.
FWIW, the word "Math" on its own is fairly geographically localised.
The base word Mathematics is less localised. However, given that
the
module has always been known as "Math", there are no qualms from me
in
staying with that term.
Staying with the old name is much less of a problem than staying
with the old ways.
Which "old ways"? I certainly hope you do not plan on shooting
yourself in
the foot by breaking BC on purpose.
Gary
IIRC, BC has never been broken in the last 7+ years, thanks to changing
the
package name.
Yet this non-issue comes back every time I indicate that a project like
CM
cannot be based on the postulate that refactoring is never needed.
The package name changes, hence the whole library can change while BC
being
still safe.
The old ways are that the default is that the same code gets
transported to
the new package so that users can use old code in new clothes, just
applying
a trivial search and replace.
That's (relatively) fine when all the current developers agree that no
better alternative can be provided for the next release.
When a problem has been identified, the new release should be taken as
an
opportunity to solve it, even if it implies refactoring (and thus a
major
release). [Someone said that we won't run out of release numbers.]
If an identified need for bridging between old and new design arises,
it
will be more interesting to find a way to achieve that, rather than
having
to beg for every change on the assumption that some unknown user might
be
unduly, affected by the evolution of the library (which is not true if
the
package name has changed).
Having multiple JARs would also alleviate the tension (provided that we
drop
the postulate that everything should be "stable").
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
