I agree. I don't think we should mandate this either.
On 10/29/06, Rory Winston <[EMAIL PROTECTED]> wrote:
That should be "an appropriate solution *for everybody*" Rory Winston wrote: > +1 > > I agree this is an issue which package maintainers will need to > consider when making major releases. I dont believe that mandating > package name changes is an appropriate solution. > > Niall Pemberton wrote: >> On 10/29/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote: >>> PROPOSAL: >>> The major version number of a component, where it is greater than 1, >>> shall be included in the package name. >>> >>> EXAMPLE: >>> org.apache.commons.pool - version 1.x line >>> org.apache.commons.pool2 - version 2.x line >>> >>> RATIONALE: >>> Java has no mechanism for handling different versions of the same >>> library where those versions clash. This leads to a situation known as >>> 'jar hell'. >>> >>> Consider application A dependent on frameworks M and N, both of which >>> depend on a commons component X. >>> >>> A >>> | >>> ----- >>> | | >>> M N >>> | | >>> ----- >>> | >>> X >>> >>> Now consider what happens if framework M upgrades to a later version of >>> X, but N does not. The standard approach is to drop in X2 and hope that >>> N still runs. >>> >>> A >>> | >>> ----- >>> | | >>> M N >>> | | >>> ----- >>> | >>> X2 >>> >>> However N may not run with X2 if the changes from X to X2 are major and >>> incompatible (which should be signalled via a major version change). >>> >>> Given this situation, the application now has no simple options. >>> They can: >>> a) give up and not upgrade framework M >>> b) petition framework N to upgrade >>> c) dive into the open source and upgrade N themselves >>> d) use two classloaders >>> e) use fancy bytecode weaving tricks to merge the versions >>> f) use jar embedding tools to alter N >>> >>> I would argue that the majority of developers would choose option (a) >>> and give up. This is because while options b-f are possible, they are >>> not what the average *user* wants to spend their time doing. >>> >>> Of course, all of this presents a very simple example. Most open source >>> stacks are much deeper than this and thus the potential for jar hell is >>> much higher. >>> >>> The proposed solution is to rename the package of each commons >>> component >>> at each major version change. This binds all the callers of the commons >>> component to a different package namespace, and thus no clashes, or jar >>> hell will ensue - except by human error. >>> >>> Why now? Because this is the time that the majority of components are >>> starting to consider new incompatible versions, often related to >>> JDK1.5. >>> >>> DOWNSIDES: >>> - The client application has to change their package names when >>> upgrading to a later major version of the commons component. >>> >>> - The client may get two versions of the same class in their IDE >>> autocomplete (most IDEs allow this to be filtered). >>> >>> >>> This proposal is about making upgrades *predicatable* at the expense of >>> a small amount of pain. I know that most of us don't really like it, >>> but >>> I contend that there is no alternative other than to inflict pain on >>> users of commons over the next few years, and perhaps risk commons >>> becoming irrelevant by being unusable. I also strongly believe we >>> need a >>> cross-commons approach on this. >> >> Its perfectly possible for a component to have a major upgrade without >> breaking backwards compatibility and I don't think we should mandate >> this. Even when there is a break in backwards compatbility, then using >> a deprecate / remove cycle should also be open as an option. There may >> be a number of factors which influence the approach to take - how >> widely used/depended on the component is, how major or minor the >> in-compatibility is and how long / many versions the feature has been >> deprecated before being removed/changed. This should be decided by the >> component developers on a component by component basis and not >> mandated as a policy. >> >> There are clearly good reasons / circumstances to take the approach >> you suggest, but it is a user unfriendly approach. As a user I like to >> try out new versions by dropping in a new jar - before taking the >> decision to upgrade. This approach rules that out and it wouldn't >> surprise me if users started to see commons as irrelevant because of >> "upgrade hell" if we take this route too often. >> >> Niall >> >> >>> Stephen >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
