> On Oct 8, 2013, at 7:08 AM, James Carman <ja...@carmanconsulting.com> wrote: > >> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <ebo...@apache.org> wrote: >> >> That's not the issue. We want to avoid unresolvable incompatibilities in >> transitive dependencies. Our components are used by many projects, an >> incompatibility could render impossible the use of two components >> together, and you are stuck until the components are updated to use the >> same version of the common dependency. >> >> ASM and BouncyCastle are two examples of widely used projects that don't >> care at all about the compatibilities, and this is causing pain and >> wasting time to a lot of smart people. > > I think you misunderstand my intent. We have left out features before > (ones that folks blogged about and said they liked) because a user > could do something stupid with it. > > What you're talking about is "jar hell" and we have already addressed > that with our naming convention for major release bumps (changing > artifactId and package name). I'm cool with that idea and I think > it's a pretty good approach. I don't see anyone else doing it, which > is interesting. > I agree that the policy we have now to change package names is reasonable, but it has two drawbacks, one for us and one for users. For us, it forces us to branch and cut a new major release each time we want/need to release something with a compat break. For users, it forces them to redo all of their imports and swallow whatever other refactoring we have thrown in to the major release. I think it makes sense to relax a bit and allow
0) some kind of annotation or naming scheme that allows us to mark classes as "internal" 1) a way to judge some compat breaks even outside the stuff in 0) as "minor" and allow them between major releases. In theory Gump and downstream packaging tools could be used to verify 1), as well as lots of notification / time for comment. I am not sure fixed rules could be defined for it though. We have actually done it a couple of times in [math] and never had anyone scream (though there have been some complaints about API stability in general - which would somewhat ironically likely be improved if we allowed ourselves a little leeway in 0) and 1)) Phil > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
