On 2/3/16 8:58 AM, 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, but for quite I > while lots of folks (myself included) continued using Commons HttpClient > because the new version was regarded as immature. 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.
Thanks, Ralf. The point above, made also by Patrick, is what changed my vote from my initial suggestion "MathComponents" to just "math." Phil > > 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 >> <mailto:dev-unsubscr...@commons.apache.org> >> For additional commands, e-mail: dev-h...@commons.apache.org >> <mailto:dev-h...@commons.apache.org> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
