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. 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>
