Okay, so what I'm hearing is that we want to relax our "no API breaks within a major release" policy. Also, it sounds like we need to come up with the naming convention where we can rope off parts of our API as implementation details and they're not to be relied upon by outside parties (they may do so at their own peril).
On Tue, Oct 8, 2013 at 12:22 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > > >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
