commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rory Winston <rwins...@eircom.net>
Subject Re: [PROPOSAL] Major versions require package name change
Date Mon, 30 Oct 2006 00:02:22 GMT
+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


Mime
View raw message