On Wed, 3 Feb 2016 08:58:19 -0700, Ralph Goers wrote:
Just my 2 cents.
When HttpClient left Commons I believe they took that opportunity to
re-architect their code. In the end I think it paid off,
Thanks for mentioning it.
I indeed see the move as a similar opportunity.
but for quite
I while lots of folks (myself included) continued using Commons
HttpClient because the new version was regarded as immature.
That would be fine, I think.
I indirectly suggested as much by saying that people who are
happy with older versions Commons Math don't need to upgrade.
It remains to define a sustainable bug-fixing policy for these
old versions.
They
also wanted to widen their scope a bit so they went from Apache
Commons HttpClient to Apache Http Components.
I don’t contribute to or use Apache Math myself, but given my
experience with HttpClient I would say that using a name that strays
very far from Math would be doing yourselves a disservice. It is a
bit of a stretch to expect people to remember that Commons Math is
now
Apache Aardvark or some other obscure name when the one you have is
pretty much perfect. The only way people will find you is via a link
on the Commons home page whereas math.apache.org
<http://math.apache.org/> just makes sense & is easy to remember.
That's a valid argument, just not the only one.
IMO, a change of name would have been a good opportunity to stress a
change in the development management.
Keeping the same name seems to announce similar "change but no change"
for other issues that have been stagnant for years. I hope that the
(near) future will prove my fear was not justified.
Regards,
Gilles
Ralph
On Feb 2, 2016, at 8:29 PM, Gilles <gil...@harfang.homelinux.org>
wrote:
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
