Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
MIME-Version: 1.0
In-Reply-To: <56A68CBF.7010204@gmail.com>
References: <56A53D38.30306@gmail.com>
	<CALznzY5_CaAWt1Ko1gkEwzuViOujMJ4ef5LT5cVr10CrNTHs_w@mail.gmail.com>
	<56A54629.6040802@gmail.com>
	<b6fe968e048afe59bddc53d0d7704536@scarlet.be>
	<75CF5FE2-6D3E-41B4-81BD-F211DF6ED168@gmail.com>
	<56A5D17E.9070101@gmail.com>
	<CAB917R+YpYnzR+BjUfSVzkRjP1BqaqMJjc6FeFQ-+xMwmc2Jtg@mail.gmail.com>
	<0c8a1cca46e7d54f8a243032a3f32bb0@smtp.spaceroots.org>
	<CAOGo0VYXsvcd6C2EW2YuLuv21LbE-FOu710vAMw0KUhb+ZfpyQ@mail.gmail.com>
	<56A65493.1020500@gmail.com>
	<CACZkXPwBjwUiuVGkMFwaDNHo2Lp6hGG8kCXyO1ra75MZowqw+A@mail.gmail.com>
	<8a871da9f3770ebd1337314de0f738bd@scarlet.be>
	<56A66544.80601@apache.org>
	<CACZkXPxHfrAKuNTVpffZSRN8Js941b9TdH9snnMvydpXnYgWyA@mail.gmail.com>
	<56A68CBF.7010204@gmail.com>
Date: Mon, 25 Jan 2016 13:49:40 -0800
Message-ID: 
 <CACZkXPynRcv-RqjuUsCWPU_ttgjC8wceSJF-KHq0hfrk7wMApg@mail.gmail.com>
Subject: Re: [math] Name of the new TLP
From: Gary Gregory <garydgregory@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=001a11c372bcd090d4052a2f8b05

--001a11c372bcd090d4052a2f8b05
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Jan 25, 2016 12:59 PM, "Thomas Neidhart" <thomas.neidhart@gmail.com>
wrote:
>
> On 01/25/2016 09:27 PM, Gary Gregory wrote:
> > On Jan 25, 2016 10:11 AM, "Emmanuel Bourg" <ebourg@apache.org> wrote:
> >>
> >> Le 25/01/2016 18:52, Gilles a =C3=A9crit :
> >>
> >>> AFAICT, the real issue is one of policy: Commons is supposed to be
> > stable,
> >>> stable, stable and stable (IIUC).
> >>>
> >>> And CM is far from being mature as a programming project, when
> > considering
> >>> design and scope, and not only the quality of its results and
> > performance
> >>> (which are both good in many cases).
> >>> So stability (as in using JDK 5 only) is not a good perspective
(surely
> > not
> >>> developers and probably not for users either IMO).
> >>>
> >>> If this does not change, what's the point indeed?
> >>
> >> I hope that a motivation behind the TLP isn't to break the
compatibility
> >> on every release, otherwise this will quickly turn into a nightmare fo=
r
> >> the users. Bouncycastle plays this game and it isn't really fun to
follow
> > :(
> >
> > WRT compatibility, the only thing that matters is not creating jar hell
for
> > users. You can break compatibility if you change package and maven
> > coordinates. It's up to the project to create enough alphas and betas t=
o
> > get to a stable public API before a release. That's just basic project
> > management IMO. Anything less will leave a lot users unhappy.
>
> What you describe is the mantra of Commons and while I perfectly agree
> with it for certain wide-spread libraries like lang, collections or
> logging, the same can not be applied to any other type of library in
> existence.

Must discuss over beers and laughs, just so I do not come across as I'm not
sure what!

The POV about is just not realistic, no matter the library. I know from
personal experience with Apache CXF 2 vs. 3, where CXF did not repackage,
and oh the pain.

What is painful is when you operate in a large stack, say depending on CXF,
Jetty, ActiveMQ, Commons, Teiid and a bunch more. In stacks like these you
do not control all transitive deps, and may the good lord help you if
different parts of the stack depend on diffetent versions of the same
conponents that are not binary compatible. Adding OSGi and/or your own
class losder hacks is not how I want to spend my time.

If everybody plays by the same BC rules, all is well.

Gary

>
> A library like CM is much less used and the danger of creating a jar
> hell because of it does not justify such a strict policy. In fact the
> Commons policy is one of the reasons why the vote to move to a TLP was
> started originally.
>
> There are also other, very respected and mature libraries (like
> joda-time) that allow non-compatible changes in major version without
> changing package / artefact ids, and the world did not collapse because
> of it.
>
> The key point is to be reasonable about the audience of a library, and
> CM does not play in the same league as lang or collections for example.
> Also a better modularization of the project might help in this respect,
> as certain modules might have different maturity levels and users can
> expect them to not change much over time, whereas others are more likely
> to change but their use is mainly in very specific applications (think
> about the optimization package in CM).
>
> We certainly need to think about and express the way we want to organize
> CM as a TLP, which really needs to be different to the status quo. I
> really hope that the people willing to contribute to CM as a TLP take
> this into account, as otherwise there is no point in doing it as Gilles
> pointed out correctly.
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

--001a11c372bcd090d4052a2f8b05--