commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject Re: [PROPOSAL] Major versions require package name change
Date Mon, 30 Oct 2006 11:19:50 GMT
I agree.  I don't think we should mandate this either.

On 10/29/06, Rory Winston <rwinston@eircom.net> 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 <scolebourne@btopenworld.com> 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: commons-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message