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