On Tue, 21 Jun 2016 11:30:13 -0400, Rob Tompkins wrote:
On Jun 21, 2016, at 11:10 AM, Gilles <gil...@harfang.homelinux.org>
wrote:
Hello.
On Tue, 21 Jun 2016 09:58:40 +0200, Jörg Schaible wrote:
Hi Jochen,
Jochen Wiedmann wrote:
On Tue, Jun 21, 2016 at 9:12 AM, Jörg Schaible
<joerg.schai...@bpm-inspire.com> wrote:
That depends. If some packages of the current CM should stay as
own
component in Commons, these packages have to be identified.
Whoever would support such a lunacy? Either CM moves entirely, or
not at
all.
It's not that clear-cut.
Thank you (and James, and Niall) for keeping the ball moving, at a
point where I was thinking that the game was over. However, we
should
all realize that it's not because that all those codes were
developed
within a single repository that they all belong together.
[We got into this dire situation because so much code _depended_
(however
people here want to put it differently) on one or two people.
And it's not a size problem, per se; it's that it covers a very
broad
scope, requiring expertise levels that are rarely found in one
person,
even less so in a person who'd dedicated (him)herself to maintaining
a
Java library. A TLP is something to attempt but I'm not optimistic
that
we'll get much more traction.]
By having some of the functionality severed from CM, it _increases_
the
likelihood that it will be used and contributed to.
And if this functionality is actually "mature", then it won't have
to
be (fakely) upgraded (through changing of package name) just because
some other (non-mature) code would need it (to allow breaking
changes).
By way of consequence, such "split off" code will fulfill the
Commons'
promise of stability.
In turn, the separation will have positive effects on the
prospective
TLP, if just by not having to deal with issues thus become
"out-of-scope".
There may well be interactions between the TLP and Commons whenever
the
TLP would choose to depend on a Commons component, but there will be
clear API boundaries.
If the new Commons Components have been identified, we can have a
vote. Then
we'll see what the majority want. All I can say now is that we have
currenty
no consensus about anything. Some of the stuff in CM is certainly
common
enough to build a valid Commons component.
At last, we agree on this! [That was my main point since day one
(June 5).]
Instead of readily discussing the consequence of that observation,
we fought
about "micro-management" of Commons Math... :-(
I'll start a VOTE thread for each new Commons component candidate.
Would it make sense here to simply leave commons-math named commons
math (mainly because mathematical naming conventions differ from the
conventional vernacular [e.g. an artifact named commons-analysis
might
be confusing]), and deprecate anything that we plan to take and move
to the incubator/TLP?
Deprecating something makes sense only if we intend to release CM 4.0,
which I'm against, since it would give users the false impression that
they should upgrade, while in fact they should switch to the new
TLP/new
Commons components releases.
An alternative would be to release a v3.6.2 with the "@Deprecated"
annotations (and no other changes). But I don't know that it is a
common practice to tell users to upgrade just so they can see the
deprecation messages (and do nothing about it since the replacement is
in another library).
You are quite right about a name like "commons-analysis" (but see my
other message; hence that issue probably won't materialize).
For the components which I'll submit to the vote, we'll be able to
easily find unambiguous names.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
