On Jan 25, 2016 12:59 PM, "Thomas Neidhart" <thomas.neidh...@gmail.com> wrote: > > On 01/25/2016 09:27 PM, Gary Gregory wrote: > > On Jan 25, 2016 10:11 AM, "Emmanuel Bourg" <ebo...@apache.org> wrote: > >> > >> Le 25/01/2016 18:52, Gilles a écrit : > >> > >>> 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 for > >> 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 to > > 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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org >
