You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2006/10/29 12:35:02 UTC
[PROPOSAL] Major versions require package name change
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.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL] Major versions require package name change
Posted by James Carman <ja...@carmanconsulting.com>.
I agree. I don't think we should mandate this either.
On 10/29/06, Rory Winston <rw...@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 <sc...@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
Re: [PROPOSAL] Major versions require package name change
Posted by Rory Winston <rw...@eircom.net>.
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 <sc...@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
Re: [PROPOSAL] Major versions require package name change
Posted by Rory Winston <rw...@eircom.net>.
+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 <sc...@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
Re: [PROPOSAL] Major versions require package name change
Posted by Torsten Curdt <tc...@apache.org>.
On 10/30/06, Niall Pemberton <ni...@gmail.com> wrote:
> On 10/30/06, Torsten Curdt <tc...@apache.org> wrote:
> > > 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.
...
> I didn't argue in this thread against changing package names - just
> against mandating it as a policy.
Even re-reading the above paragraph that is not what I am reading in
it ...but anyway.
> I agree that if, as in the example of Generified Collections, the
> developers choose to refactor then changing the package name is a
> necessary approach. However the Collections developers have/had a
> choice - they could have adopted the approach Sun took to generics and
> preserved backwards compatibility.
I think that's not even what this proposal is about. It's about the case when
it is either not possible ...or decided not to keep this
compatibility. So if there
is no way of "dropping in" the jar there should be a change of the major
version number ....AND so this should also require a package name change.
It think this is about contracts ...and all components should adhere to that.
What we do with Collections should be discussed outside this thread ...IMO
> Both options are valid - but it
> should be down to individual components to choose the route they take.
> If Collections had chosen this route then mandating a package name
> change would be stupid.
> P.S. Your analogy is irrelevant as it doesn't represent any POV I put forward.
Without putting oil into a fire I'd like to carefully note that
"Irrelevant" and "stupid"
are words you should be careful with in discussions.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL] Major versions require package name change
Posted by Niall Pemberton <ni...@gmail.com>.
On 10/30/06, Torsten Curdt <tc...@apache.org> wrote:
> > 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.
>
> Guys, you cannot always just "drop in a new jar". Come on!
>
> A similar conversation that could have happened a couple of years ago...
>
> you: "No, I don't like this 3.5" floppy drives. They don't fit my 5 1/4" disks!"
> me: "Well, it's new, it's different ...it has more capacity!"
> you: "Well, I don't care ...I used to be able to use them. I don't
> want the new disks ...but the capacity would be great. I just want to
> have that."
> me: "Just keep using you old drive then ...but you would have to stick
> with the old capacity"
> you: "No, now I want the bigger capacity!!"
> me: "Then you will have to copy over the data from the old disks to
> some new ones"
> you: "Are you kidding? That's too much work! I used to just stick them
> in there and they just worked fine! If it's that much work to use this
> new fancy drives - no one will use this crap"
> me: *sigh*
> *silence*
>
> (you = multiple people arguing in this thread not to change the package name)
> (me = the other people arguing in this thread who think it would
> probably make sense)
> (silence = the rest of the gang ;-) )
I didn't argue in this thread against changing package names - just
against mandating it as a policy.
I agree that if, as in the example of Generified Collections, the
developers choose to refactor then changing the package name is a
necessary approach. However the Collections developers have/had a
choice - they could have adopted the approach Sun took to generics and
preserved backwards compatibility. Both options are valid - but it
should be down to individual components to choose the route they take.
If Collections had chosen this route then mandating a package name
change would be stupid.
Niall
P.S. Your analogy is irrelevant as it doesn't represent any POV I put forward.
> Keep in mind you can still use the "drop in upgrade" for minor
> releases. If there is a major release - there is a good reason for it!
> If this "drop in" would have been possible it would have been a minor
> release. So how often would you thinks this will happen? And...
>
> Upgrading a package name change is easily manageable by the average
> user ...dependency hell is not.
>
> So I think using this scheme would make things quite transparent and
> HELP the users.
>
> cheers
> --
> Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL] Major versions require package name change
Posted by James Carman <ja...@carmanconsulting.com>.
I think the point is that we don't think this should be mandated and
up to the individual project teams to decide what they want to do. I
would agree that this option should be standardized (appending the
major release version number to the package name) so that folks know
what's going on if it does happen. Requiring every project to do so
seems a bit heavy-handed, though. If this were a requirement for
every major release, then I think folks would be hesitant to do a
major release.
On 10/30/06, Torsten Curdt <tc...@apache.org> wrote:
> > 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.
>
> Guys, you cannot always just "drop in a new jar". Come on!
>
> A similar conversation that could have happened a couple of years ago...
>
> you: "No, I don't like this 3.5" floppy drives. They don't fit my 5 1/4" disks!"
> me: "Well, it's new, it's different ...it has more capacity!"
> you: "Well, I don't care ...I used to be able to use them. I don't
> want the new disks ...but the capacity would be great. I just want to
> have that."
> me: "Just keep using you old drive then ...but you would have to stick
> with the old capacity"
> you: "No, now I want the bigger capacity!!"
> me: "Then you will have to copy over the data from the old disks to
> some new ones"
> you: "Are you kidding? That's too much work! I used to just stick them
> in there and they just worked fine! If it's that much work to use this
> new fancy drives - no one will use this crap"
> me: *sigh*
> *silence*
>
> (you = multiple people arguing in this thread not to change the package name)
> (me = the other people arguing in this thread who think it would
> probably make sense)
> (silence = the rest of the gang ;-) )
>
> Keep in mind you can still use the "drop in upgrade" for minor
> releases. If there is a major release - there is a good reason for it!
> If this "drop in" would have been possible it would have been a minor
> release. So how often would you thinks this will happen? And...
>
> Upgrading a package name change is easily manageable by the average
> user ...dependency hell is not.
>
> So I think using this scheme would make things quite transparent and
> HELP the users.
>
> cheers
> --
> Torsten
>
> ---------------------------------------------------------------------
> 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
Re: [PROPOSAL] Major versions require package name change
Posted by Torsten Curdt <tc...@apache.org>.
> 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.
Guys, you cannot always just "drop in a new jar". Come on!
A similar conversation that could have happened a couple of years ago...
you: "No, I don't like this 3.5" floppy drives. They don't fit my 5 1/4" disks!"
me: "Well, it's new, it's different ...it has more capacity!"
you: "Well, I don't care ...I used to be able to use them. I don't
want the new disks ...but the capacity would be great. I just want to
have that."
me: "Just keep using you old drive then ...but you would have to stick
with the old capacity"
you: "No, now I want the bigger capacity!!"
me: "Then you will have to copy over the data from the old disks to
some new ones"
you: "Are you kidding? That's too much work! I used to just stick them
in there and they just worked fine! If it's that much work to use this
new fancy drives - no one will use this crap"
me: *sigh*
*silence*
(you = multiple people arguing in this thread not to change the package name)
(me = the other people arguing in this thread who think it would
probably make sense)
(silence = the rest of the gang ;-) )
Keep in mind you can still use the "drop in upgrade" for minor
releases. If there is a major release - there is a good reason for it!
If this "drop in" would have been possible it would have been a minor
release. So how often would you thinks this will happen? And...
Upgrading a package name change is easily manageable by the average
user ...dependency hell is not.
So I think using this scheme would make things quite transparent and
HELP the users.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL] Major versions require package name change
Posted by Niall Pemberton <ni...@gmail.com>.
On 10/29/06, Stephen Colebourne <sc...@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
RE: [PROPOSAL] Major versions require package name change
Posted by Gary Gregory <gg...@seagullsoftware.com>.
In my mind, name vs. name2 makes sense seems for a next generation based
on new code rather than a next version.
Thank you,
Gary
> -----Original Message-----
> From: sandymac@gmail.com [mailto:sandymac@gmail.com] On Behalf Of
Sandy
> McArthur
> Sent: Monday, October 30, 2006 9:41 AM
> To: Jakarta Commons Developers List
> Subject: Re: [PROPOSAL] Major versions require package name change
>
> On 10/29/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> > PROPOSAL:
> > The major version number of a component, where it is greater than 1,
> > shall be included in the package name.
>
> I gotta disagree with this.
>
> If we want to come up with the notion of a "super" version, something
> that is more broad than a "major" version and includes non-backwards
> compatible changes I'm fine with that.
>
> But mandating that any major release be completely non-backwards
> compatible is silly.
>
> Occasional drastic pruning of code is needed to keep it healthy and
> manageable. But we should not be eager to run out and break
> compatibility without deliberate and compelling reasons.
>
> --
> Sandy McArthur
>
> "He who dares not offend cannot be honest."
> - Thomas Paine
>
> ---------------------------------------------------------------------
> 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
Re: [PROPOSAL] Major versions require package name change
Posted by Sandy McArthur <sa...@apache.org>.
On 10/29/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> PROPOSAL:
> The major version number of a component, where it is greater than 1,
> shall be included in the package name.
I gotta disagree with this.
If we want to come up with the notion of a "super" version, something
that is more broad than a "major" version and includes non-backwards
compatible changes I'm fine with that.
But mandating that any major release be completely non-backwards
compatible is silly.
Occasional drastic pruning of code is needed to keep it healthy and
manageable. But we should not be eager to run out and break
compatibility without deliberate and compelling reasons.
--
Sandy McArthur
"He who dares not offend cannot be honest."
- Thomas Paine
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL] Major versions require package name change
Posted by Rahul Akolkar <ra...@gmail.com>.
On 10/29/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
<snip/>
>
> 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.
>
<snap/>
Predictable, cross-commons, whats not to like.
I don't know if we risk being unusable, but we may risk being obsolete
first if we keep dragging our baggage. When sweeping changes are
expected out of components, its a good time to go all out.
-Rahul
> Stephen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL] Major versions require package name change
Posted by Joerg Heinicke <jo...@gmx.de>.
Torsten Curdt <tcurdt <at> apache.org> writes:
> > I really wonder why this should be a concern of the actual component at all.
> > A component is an encapsulated piece of software with a well-defined
> > interface (here API). If there are problems in the environment in using this
> > component or looking it up (here jar hell/classpath), then this is a problem
> > of the environment, not a concern of the component. Therefore this thing has
> > also to be fixed in the environment.
> >
> > Classloader shielding is an appropriate solution.
>
> Classloader shielding does not help if your application uses libA and libB
> both having dependencies on libC ...but of different versions - that are
> incompatible.
>
> I fail see how that is environment related.
It is in so far as the application has a problem by using libA and libB. libC
itself has no problem, but its users. So it is not the component, but the
environment.
Just put the shielding on a lower (than the application) level and it works
again, doesn't it?
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL] Major versions require package name change
Posted by Torsten Curdt <tc...@apache.org>.
On 11/7/06, Joerg Heinicke <jo...@gmx.de> wrote:
> Stephen Colebourne <scolebourne <at> btopenworld.com> writes:
>
> > PROPOSAL:
> > The major version number of a component, where it is greater than 1,
> > shall be included in the package name.
>
> I really wonder why this should be a concern of the actual component at all. A
> component is an encapsulated piece of software with a well-defined interface
> (here API). If there are problems in the environment in using this component or
> looking it up (here jar hell/classpath), then this is a problem of the
> environment, not a concern of the component. Therefore this thing has also to be
> fixed in the environment.
>
> Classloader shielding is an appropriate solution. There is much ongoing work
> like OSGi to standardize this and make it easier usable. So I wonder why this is
> now still such a major topic though it worked ten years without it. Maybe in 2
> or 3 years nobody will talk about it at all when classloader shielding is so
> common and easily usable.
Classloader shielding does not help if your application uses libA and libB both
having dependencies on libC ...but of different versions - that are
incompatible.
I fail see how that is environment related.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL] Major versions require package name change
Posted by Joerg Heinicke <jo...@gmx.de>.
Stephen Colebourne <scolebourne <at> btopenworld.com> writes:
> PROPOSAL:
> The major version number of a component, where it is greater than 1,
> shall be included in the package name.
I really wonder why this should be a concern of the actual component at all. A
component is an encapsulated piece of software with a well-defined interface
(here API). If there are problems in the environment in using this component or
looking it up (here jar hell/classpath), then this is a problem of the
environment, not a concern of the component. Therefore this thing has also to be
fixed in the environment.
Classloader shielding is an appropriate solution. There is much ongoing work
like OSGi to standardize this and make it easier usable. So I wonder why this is
now still such a major topic though it worked ten years without it. Maybe in 2
or 3 years nobody will talk about it at all when classloader shielding is so
common and easily usable.
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org