The only relaxing I could see is for code in internal packages. Gary
On Oct 8, 2013, at 12:28, James Carman <ja...@carmanconsulting.com> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
