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:03:41 GMT
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


Mime
View raw message