commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [math] Name of the new TLP
Date Wed, 03 Feb 2016 03:29:32 GMT
On Tue, 2 Feb 2016 18:52:24 -0800, Gary Gregory wrote:
> On Tue, Feb 2, 2016 at 6:24 PM, Gilles <gilles@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 <meyerjp3@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message