You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2012/11/22 14:46:40 UTC
[DISCUSS] Deprecated code policy
Folks
There are lots of changes planned for the 4.3 series that will require
many of the old implementation classes to be deprecated in favor of
newer ones with a different API. While the amount of deprecated code
will be moderate in HttpCore there will be LOTS of it in HttpClient. We
should start thinking how we want to go about deprecated code in the 4.x
code line.
(1) We could keep deprecated functionality indefinitely to maximize
compatibility. In this case we should start thinking about 5.0 and API
incompatible changes soonish as we have already accumulated quite a lot
of deprecated legacy code.
(2) Alternatively, we could be selectively removing deprecated code
after a certain number of feature releases (two feature releases) and a
certain grace period (approximately two years) and keep 5.0 for some
really major changes such as HTTP/2.0 or HTTP/1.1bis. By the way, this
is what we have done about stuff deprecated in 4.0 GA.
I am leaning more towards option 2 and therefore would like to proceed
with removal of code deprecated in the 4.1 release from the 4.3 branch
(both HttpCore and HttpClient).
What are your thoughts? What would be your preference?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [DISCUSS] Deprecated code policy
Posted by "Asankha C. Perera" <as...@apache.org>.
On 11/22/2012 07:16 PM, Oleg Kalnichevski wrote:
> ...
> (2) Alternatively, we could be selectively removing deprecated code
> after a certain number of feature releases (two feature releases) and a
> certain grace period (approximately two years) and keep 5.0 for some
> really major changes such as HTTP/2.0 or HTTP/1.1bis. By the way, this
> is what we have done about stuff deprecated in 4.0 GA.
>
> I am leaning more towards option 2 and therefore would like to proceed
> with removal of code deprecated in the 4.1 release from the 4.3 branch
> (both HttpCore and HttpClient).
+1
asankha
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [DISCUSS] Deprecated code policy
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Nov 22, 2012 at 1:40 PM, sebb <se...@gmail.com> wrote:
> On 22 November 2012 18:03, Gary Gregory <ga...@gmail.com> wrote:
> > Hi all,
> >
> > <ot>
> > For US folks out there on the interwebs, Happy Thanksgving day to you
> > all. In this context, I am thankful for this community of like and
> > open-minded software gurus, tinkerers, and bit wranglers.
> > </ot>
> >
> > I find it helpful to think about this in two parts: process and labeling
> > (or what version to label code). This is my perfect version world:
> >
> > Process:
> >
> > I like to release one version N that includes @[D|d]eprecated code with a
> > comment that states the EOL policy, e.g. "This class/method will be
> removed
> > in version A.B" *AND* the doc MUST contain a pointer to what to do
> instead.
> >
> > The simplest process is to deprecate in version N and remove in the next
> > (major) version N+1, e.g. 4.2 and 5.0.
> >
> > Labeling:
> >
> > Strictly, speaking I like API breakage in "major" releases only: 4.0,
> 5.0,
> > 6.0 and so on. It's just simpler to think about even if it leads to
> > "version inflation". When I pick up a new major version, I know what I am
> > in for. In Commons-land, this is also an opportunity to offer co-location
> > as a feature by renaming the package from o.a.project to o.a.project2,
> > o.a.project3, and so on. This is what Commons Lang did for version 3. The
> > POM AID should also be renamed at this time.
> >
> > I would only deprecate in a minor release (4.3), not a maintenance
> release
> > (4.2.3). That's just because I don't expect surprises in maintenance
> > releases, I expect a maint. release to be used in a drop and go fashion
> > without deprecated warnings popping up. IOW, no new APIs in a maint
> release.
> >
> > HTTP Components
> >
> > How does this match up with this project? What's a good pragmatic
> approach?
> >
> > Well, now is a good time to talk about this since HttpClient will offer a
> > new API.
> >
> > Today I can co-locate (I'm not sure what to call this feature)
> HttpClient 3
> > and 4 because, this project is now a TLP and has a different package
> name.
>
> HC4 is a completely different product from HC3, whereas what we are
> discussing now is a gradual evolution.
>
Technically yes but not to customers, it's still "HttpClient", whether it
is "Apache Commons HC" or "Apache HttpComponents HC".
>
> > So my first question is: do we want to 'break' co-location for the new
> > version or keep it? Do we want HC Next to live next to HC 4.2?
> >
> > The other way to ask this is: why would you not want to co-locate v4 and
> > vNext.
>
> Co-location - i.e. allowing both to play nicely in the same
> classloader - is only necessary if there are systems that *need* both.
>
And that happens all the time when you are dealing with our kinds of
products. For example, my product at work depends on many third party
libraries like Apache CXF, Eclipse Jetty, our internal products, and lots
of other FOSS jars. The last thing I need is some headache because HC
decides to change its API and keep its packaging the same and another
dependency upgrades to the latest. You have to think about this like a
forest of trees.
The dependencies for us are always more than one level deep. We depend on
components that depend on other components and so on.
> For example, JMeter uses both HC3 and HC4, but there's no reason for
> it to use HC4 and HC4-new together.
> JMeter will be amended as necessary to be able to use the updated API.
>
See above, I need to consider a whole ecosystem that makes up a large stack
of 80+ third party dependencies. For example, Apache CXF is one dependency
and it depends on a ton of third party libs.
>
> > All of this leads me to think that the new HC API should be in a version
> 5
> > with a new package name.
>
> Changing package name (and AID) does guarantee that the different
> versions can co-exist.
> However it means a lot more changes to source code.
>
Changing an import reference from version N to version N+1 is not a lot of
work.
>
> With gradual introduction and removal of methods it's possible to phase
> updates.
> However, if HC5 were to both introduce useful new methods and remove
> deprecated ones this would make the update process slightly more
> involved.
>
> > From experience in a real world app server, I can testified that having
> > Commons Lang 2 and 3 co-located is a genius feature which has avoid us
> > countless headaches.
>
> As I already wrote, Commons Lang is a very different proposition.
> Headaches (jar hell) come from having multiple independent
> dependencies on Lang in the same classloader and not being able to
> update them all.
> If there is only one dependency on Lang, that could be updated without
> problems.
>
> If there are genuine use cases where multiple independent parts of a
> system all depend on HC4, then yes, it might be worth striving for
> strict binary compatibility.
> But otherwise I think it's probably unnecessary overhead for HC4.
>
> As to whether the next version should be 4.x or 5.0, I don't particularly
> mind.
> A major version bump may make sense at this point.
>
The overall point of all of this is that you cannot control or predict how
other products use our jars.
Gary
> > Gobble, Gobble,
> > Gary
> >
> >
> > On Thu, Nov 22, 2012 at 9:27 AM, sebb <se...@gmail.com> wrote:
> >
> >> On 22 November 2012 13:46, Oleg Kalnichevski <ol...@apache.org> wrote:
> >> > Folks
> >> >
> >> > There are lots of changes planned for the 4.3 series that will require
> >> > many of the old implementation classes to be deprecated in favor of
> >> > newer ones with a different API. While the amount of deprecated code
> >> > will be moderate in HttpCore there will be LOTS of it in HttpClient.
> We
> >> > should start thinking how we want to go about deprecated code in the
> 4.x
> >> > code line.
> >> >
> >> > (1) We could keep deprecated functionality indefinitely to maximize
> >> > compatibility. In this case we should start thinking about 5.0 and API
> >> > incompatible changes soonish as we have already accumulated quite a
> lot
> >> > of deprecated legacy code.
> >> >
> >> > (2) Alternatively, we could be selectively removing deprecated code
> >> > after a certain number of feature releases (two feature releases) and
> a
> >> > certain grace period (approximately two years) and keep 5.0 for some
> >> > really major changes such as HTTP/2.0 or HTTP/1.1bis. By the way, this
> >> > is what we have done about stuff deprecated in 4.0 GA.
> >> >
> >> > I am leaning more towards option 2 and therefore would like to proceed
> >> > with removal of code deprecated in the 4.1 release from the 4.3 branch
> >> > (both HttpCore and HttpClient).
> >> >
> >> > What are your thoughts? What would be your preference?
> >>
> >> Option 2 breaks binary compatibility, so is not suitable for all
> >> libraries (e.g. it would not be suitable for Commons components, which
> >> are likely to be referenced multiple times in the same classpath).
> >>
> >> However, in the case of HC, it seems very unlikely that a single
> >> classpath will contain multiple independent dependencies on HC.
> >>
> >> So Option 2 seems the best way forward in this case.
> >>
> >> > Oleg
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> >> > For additional commands, e-mail: dev-help@hc.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> >> For additional commands, e-mail: dev-help@hc.apache.org
> >>
> >>
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [DISCUSS] Deprecated code policy
Posted by William Speirs <ws...@apache.org>.
My vote is for #2.
Thanks!
Bill-
On Fri, Nov 23, 2012 at 8:13 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Fri, 2012-11-23 at 08:18 +0000, James Abley wrote:
> > I don't know if you can use semantic versioning [1], or if apache
> projects
> > have a different way of defining major / minor / point version changes?
> >
> > [1] http://semver.org/
> >
>
> ...
>
> >
> > On 23 November 2012 00:00, sebb <se...@gmail.com> wrote:
> >
> > >
> > > If we wish to support Spring we still have to maintain strict binary
> > > compatibility within a given package name and associated AID.
> > >
> > > > policy in this regard and stick to it we will be acting responsibly
> > > > enough given the existing project constraints.
> > >
> > > The policy also has to be workable within the likely usage scenarios.
> > >
> > > For example, for JMeter it would be fine to drop deprecated methods
> > > after a couple of releases, but AFAICT that is not the case for
> > > Spring.
> > > There's no guarantee that all the Spring components can be upgraded
> > > within a given release time-frame - or indeeed ever -so breaks in
> > > compatibilty must be accompanied by a change in package name/AID.
> > >
>
> @Sebastian
>
> All right. So be it.
>
> @James
>
> Given the outcome of this discussion the versioning policy we de facto
> have in HC is equivalent to the semantic versioning described in the
> document with very minor deviations (x.y-alpha1 instead of x.y.z-alpha1
> and so on).
>
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: [DISCUSS] Deprecated code policy
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2012-11-23 at 08:18 +0000, James Abley wrote:
> I don't know if you can use semantic versioning [1], or if apache projects
> have a different way of defining major / minor / point version changes?
>
> [1] http://semver.org/
>
...
>
> On 23 November 2012 00:00, sebb <se...@gmail.com> wrote:
>
> >
> > If we wish to support Spring we still have to maintain strict binary
> > compatibility within a given package name and associated AID.
> >
> > > policy in this regard and stick to it we will be acting responsibly
> > > enough given the existing project constraints.
> >
> > The policy also has to be workable within the likely usage scenarios.
> >
> > For example, for JMeter it would be fine to drop deprecated methods
> > after a couple of releases, but AFAICT that is not the case for
> > Spring.
> > There's no guarantee that all the Spring components can be upgraded
> > within a given release time-frame - or indeeed ever -so breaks in
> > compatibilty must be accompanied by a change in package name/AID.
> >
@Sebastian
All right. So be it.
@James
Given the outcome of this discussion the versioning policy we de facto
have in HC is equivalent to the semantic versioning described in the
document with very minor deviations (x.y-alpha1 instead of x.y.z-alpha1
and so on).
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [DISCUSS] Deprecated code policy
Posted by James Abley <ja...@gmail.com>.
I don't know if you can use semantic versioning [1], or if apache projects
have a different way of defining major / minor / point version changes?
[1] http://semver.org/
On 23 November 2012 00:00, sebb <se...@gmail.com> wrote:
> On 22 November 2012 22:16, Oleg Kalnichevski <ol...@apache.org> wrote:
> > On Thu, 2012-11-22 at 18:40 +0000, sebb wrote:
> >> On 22 November 2012 18:03, Gary Gregory <ga...@gmail.com> wrote:
> >> > Hi all,
> >> >
> >> > <ot>
> >> > For US folks out there on the interwebs, Happy Thanksgving day to
> you
> >> > all. In this context, I am thankful for this community of like and
> >> > open-minded software gurus, tinkerers, and bit wranglers.
> >> > </ot>
> >> >
> >> > I find it helpful to think about this in two parts: process and
> labeling
> >> > (or what version to label code). This is my perfect version world:
> >> >
> >> > Process:
> >> >
> >> > I like to release one version N that includes @[D|d]eprecated code
> with a
> >> > comment that states the EOL policy, e.g. "This class/method will be
> removed
> >> > in version A.B" *AND* the doc MUST contain a pointer to what to do
> instead.
> >> >
> >> > The simplest process is to deprecate in version N and remove in the
> next
> >> > (major) version N+1, e.g. 4.2 and 5.0.
> >> >
> >> > Labeling:
> >> >
> >> > Strictly, speaking I like API breakage in "major" releases only: 4.0,
> 5.0,
> >> > 6.0 and so on. It's just simpler to think about even if it leads to
> >> > "version inflation". When I pick up a new major version, I know what
> I am
> >> > in for. In Commons-land, this is also an opportunity to offer
> co-location
> >> > as a feature by renaming the package from o.a.project to o.a.project2,
> >> > o.a.project3, and so on. This is what Commons Lang did for version 3.
> The
> >> > POM AID should also be renamed at this time.
> >> >
> >> > I would only deprecate in a minor release (4.3), not a maintenance
> release
> >> > (4.2.3). That's just because I don't expect surprises in maintenance
> >> > releases, I expect a maint. release to be used in a drop and go
> fashion
> >> > without deprecated warnings popping up. IOW, no new APIs in a maint
> release.
> >> >
> >> > HTTP Components
> >> >
> >> > How does this match up with this project? What's a good pragmatic
> approach?
> >> >
> >> > Well, now is a good time to talk about this since HttpClient will
> offer a
> >> > new API.
> >> >
> >> > Today I can co-locate (I'm not sure what to call this feature)
> HttpClient 3
> >> > and 4 because, this project is now a TLP and has a different package
> name.
> >>
> >> HC4 is a completely different product from HC3, whereas what we are
> >> discussing now is a gradual evolution.
> >>
> >> > So my first question is: do we want to 'break' co-location for the new
> >> > version or keep it? Do we want HC Next to live next to HC 4.2?
> >> >
> >> > The other way to ask this is: why would you not want to co-locate v4
> and
> >> > vNext.
> >>
> >> Co-location - i.e. allowing both to play nicely in the same
> >> classloader - is only necessary if there are systems that *need* both.
> >>
> >> For example, JMeter uses both HC3 and HC4, but there's no reason for
> >> it to use HC4 and HC4-new together.
> >> JMeter will be amended as necessary to be able to use the updated API.
> >>
> >> > All of this leads me to think that the new HC API should be in a
> version 5
> >> > with a new package name.
> >>
> >> Changing package name (and AID) does guarantee that the different
> >> versions can co-exist.
> >> However it means a lot more changes to source code.
> >>
> >> With gradual introduction and removal of methods it's possible to phase
> updates.
> >> However, if HC5 were to both introduce useful new methods and remove
> >> deprecated ones this would make the update process slightly more
> >> involved.
> >>
> >> > From experience in a real world app server, I can testified that
> having
> >> > Commons Lang 2 and 3 co-located is a genius feature which has avoid us
> >> > countless headaches.
> >>
> >> As I already wrote, Commons Lang is a very different proposition.
> >> Headaches (jar hell) come from having multiple independent
> >> dependencies on Lang in the same classloader and not being able to
> >> update them all.
> >> If there is only one dependency on Lang, that could be updated without
> problems.
> >>
> >> If there are genuine use cases where multiple independent parts of a
> >> system all depend on HC4, then yes, it might be worth striving for
> >> strict binary compatibility.
> >> But otherwise I think it's probably unnecessary overhead for HC4.
> >>
> >> As to whether the next version should be 4.x or 5.0, I don't
> particularly mind.
> >> A major version bump may make sense at this point.
> >>
> >
> > Co-location is a very valid and relevant subject. It is great that Gary
> > brought it up. Luckily we do not have to make a decision about it as
> > yet. HC 4.3 can be and is planned to be fully backward compatible with
> > 4.2. One should be able to simply drop 4.3 release in place of 4.2 and
> > still have everything working without any modification. The price of
> > such backward compatibility is of course having to keep two or more
> > versions of essentially the same code with some variations and a
> > different class name. The benefit of this approach is that it enables
> > users to migrate more gradually.
>
> It's only possible for a new version to be a drop-in replacement if it
> is binary compatible.
> That implies that methods cannot be deleted. [Unless they are clearly
> not part of the public API]
>
> > I think HC4 is used widely enough to result in situations where multiple
> > sub-components of the same system depend on different versions of HC4.
> > Spring alone makes such situation very likely.
>
> In which case, HC is much more like Commons than I supposed, and
> option 2 is a non-starter..
>
> > At the same time we have
> > to be realistic about our capacity to maintain deprecated functionality.
> > If we can't do it right (and we cant) we will serve our users better by
> > removing it. I personally think two year / two feature releases is a
> > reasonable time frame to expect people to migrate off deprecated code.
> > We no longer have to maintain strict binary compatibility forever just
> > to please some people at Google. As long as we clearly articulate our
>
> If we wish to support Spring we still have to maintain strict binary
> compatibility within a given package name and associated AID.
>
> > policy in this regard and stick to it we will be acting responsibly
> > enough given the existing project constraints.
>
> The policy also has to be workable within the likely usage scenarios.
>
> For example, for JMeter it would be fine to drop deprecated methods
> after a couple of releases, but AFAICT that is not the case for
> Spring.
> There's no guarantee that all the Spring components can be upgraded
> within a given release time-frame - or indeeed ever -so breaks in
> compatibilty must be accompanied by a change in package name/AID.
>
> > Oleg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: [DISCUSS] Deprecated code policy
Posted by sebb <se...@gmail.com>.
On 22 November 2012 22:16, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2012-11-22 at 18:40 +0000, sebb wrote:
>> On 22 November 2012 18:03, Gary Gregory <ga...@gmail.com> wrote:
>> > Hi all,
>> >
>> > <ot>
>> > For US folks out there on the interwebs, Happy Thanksgving day to you
>> > all. In this context, I am thankful for this community of like and
>> > open-minded software gurus, tinkerers, and bit wranglers.
>> > </ot>
>> >
>> > I find it helpful to think about this in two parts: process and labeling
>> > (or what version to label code). This is my perfect version world:
>> >
>> > Process:
>> >
>> > I like to release one version N that includes @[D|d]eprecated code with a
>> > comment that states the EOL policy, e.g. "This class/method will be removed
>> > in version A.B" *AND* the doc MUST contain a pointer to what to do instead.
>> >
>> > The simplest process is to deprecate in version N and remove in the next
>> > (major) version N+1, e.g. 4.2 and 5.0.
>> >
>> > Labeling:
>> >
>> > Strictly, speaking I like API breakage in "major" releases only: 4.0, 5.0,
>> > 6.0 and so on. It's just simpler to think about even if it leads to
>> > "version inflation". When I pick up a new major version, I know what I am
>> > in for. In Commons-land, this is also an opportunity to offer co-location
>> > as a feature by renaming the package from o.a.project to o.a.project2,
>> > o.a.project3, and so on. This is what Commons Lang did for version 3. The
>> > POM AID should also be renamed at this time.
>> >
>> > I would only deprecate in a minor release (4.3), not a maintenance release
>> > (4.2.3). That's just because I don't expect surprises in maintenance
>> > releases, I expect a maint. release to be used in a drop and go fashion
>> > without deprecated warnings popping up. IOW, no new APIs in a maint release.
>> >
>> > HTTP Components
>> >
>> > How does this match up with this project? What's a good pragmatic approach?
>> >
>> > Well, now is a good time to talk about this since HttpClient will offer a
>> > new API.
>> >
>> > Today I can co-locate (I'm not sure what to call this feature) HttpClient 3
>> > and 4 because, this project is now a TLP and has a different package name.
>>
>> HC4 is a completely different product from HC3, whereas what we are
>> discussing now is a gradual evolution.
>>
>> > So my first question is: do we want to 'break' co-location for the new
>> > version or keep it? Do we want HC Next to live next to HC 4.2?
>> >
>> > The other way to ask this is: why would you not want to co-locate v4 and
>> > vNext.
>>
>> Co-location - i.e. allowing both to play nicely in the same
>> classloader - is only necessary if there are systems that *need* both.
>>
>> For example, JMeter uses both HC3 and HC4, but there's no reason for
>> it to use HC4 and HC4-new together.
>> JMeter will be amended as necessary to be able to use the updated API.
>>
>> > All of this leads me to think that the new HC API should be in a version 5
>> > with a new package name.
>>
>> Changing package name (and AID) does guarantee that the different
>> versions can co-exist.
>> However it means a lot more changes to source code.
>>
>> With gradual introduction and removal of methods it's possible to phase updates.
>> However, if HC5 were to both introduce useful new methods and remove
>> deprecated ones this would make the update process slightly more
>> involved.
>>
>> > From experience in a real world app server, I can testified that having
>> > Commons Lang 2 and 3 co-located is a genius feature which has avoid us
>> > countless headaches.
>>
>> As I already wrote, Commons Lang is a very different proposition.
>> Headaches (jar hell) come from having multiple independent
>> dependencies on Lang in the same classloader and not being able to
>> update them all.
>> If there is only one dependency on Lang, that could be updated without problems.
>>
>> If there are genuine use cases where multiple independent parts of a
>> system all depend on HC4, then yes, it might be worth striving for
>> strict binary compatibility.
>> But otherwise I think it's probably unnecessary overhead for HC4.
>>
>> As to whether the next version should be 4.x or 5.0, I don't particularly mind.
>> A major version bump may make sense at this point.
>>
>
> Co-location is a very valid and relevant subject. It is great that Gary
> brought it up. Luckily we do not have to make a decision about it as
> yet. HC 4.3 can be and is planned to be fully backward compatible with
> 4.2. One should be able to simply drop 4.3 release in place of 4.2 and
> still have everything working without any modification. The price of
> such backward compatibility is of course having to keep two or more
> versions of essentially the same code with some variations and a
> different class name. The benefit of this approach is that it enables
> users to migrate more gradually.
It's only possible for a new version to be a drop-in replacement if it
is binary compatible.
That implies that methods cannot be deleted. [Unless they are clearly
not part of the public API]
> I think HC4 is used widely enough to result in situations where multiple
> sub-components of the same system depend on different versions of HC4.
> Spring alone makes such situation very likely.
In which case, HC is much more like Commons than I supposed, and
option 2 is a non-starter..
> At the same time we have
> to be realistic about our capacity to maintain deprecated functionality.
> If we can't do it right (and we cant) we will serve our users better by
> removing it. I personally think two year / two feature releases is a
> reasonable time frame to expect people to migrate off deprecated code.
> We no longer have to maintain strict binary compatibility forever just
> to please some people at Google. As long as we clearly articulate our
If we wish to support Spring we still have to maintain strict binary
compatibility within a given package name and associated AID.
> policy in this regard and stick to it we will be acting responsibly
> enough given the existing project constraints.
The policy also has to be workable within the likely usage scenarios.
For example, for JMeter it would be fine to drop deprecated methods
after a couple of releases, but AFAICT that is not the case for
Spring.
There's no guarantee that all the Spring components can be upgraded
within a given release time-frame - or indeeed ever -so breaks in
compatibilty must be accompanied by a change in package name/AID.
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [DISCUSS] Deprecated code policy
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Nov 22, 2012 at 5:16 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2012-11-22 at 18:40 +0000, sebb wrote:
> > On 22 November 2012 18:03, Gary Gregory <ga...@gmail.com> wrote:
> > > Hi all,
> > >
> > > <ot>
> > > For US folks out there on the interwebs, Happy Thanksgving day to you
> > > all. In this context, I am thankful for this community of like and
> > > open-minded software gurus, tinkerers, and bit wranglers.
> > > </ot>
> > >
> > > I find it helpful to think about this in two parts: process and
> labeling
> > > (or what version to label code). This is my perfect version world:
> > >
> > > Process:
> > >
> > > I like to release one version N that includes @[D|d]eprecated code
> with a
> > > comment that states the EOL policy, e.g. "This class/method will be
> removed
> > > in version A.B" *AND* the doc MUST contain a pointer to what to do
> instead.
> > >
> > > The simplest process is to deprecate in version N and remove in the
> next
> > > (major) version N+1, e.g. 4.2 and 5.0.
> > >
> > > Labeling:
> > >
> > > Strictly, speaking I like API breakage in "major" releases only: 4.0,
> 5.0,
> > > 6.0 and so on. It's just simpler to think about even if it leads to
> > > "version inflation". When I pick up a new major version, I know what I
> am
> > > in for. In Commons-land, this is also an opportunity to offer
> co-location
> > > as a feature by renaming the package from o.a.project to o.a.project2,
> > > o.a.project3, and so on. This is what Commons Lang did for version 3.
> The
> > > POM AID should also be renamed at this time.
> > >
> > > I would only deprecate in a minor release (4.3), not a maintenance
> release
> > > (4.2.3). That's just because I don't expect surprises in maintenance
> > > releases, I expect a maint. release to be used in a drop and go fashion
> > > without deprecated warnings popping up. IOW, no new APIs in a maint
> release.
> > >
> > > HTTP Components
> > >
> > > How does this match up with this project? What's a good pragmatic
> approach?
> > >
> > > Well, now is a good time to talk about this since HttpClient will
> offer a
> > > new API.
> > >
> > > Today I can co-locate (I'm not sure what to call this feature)
> HttpClient 3
> > > and 4 because, this project is now a TLP and has a different package
> name.
> >
> > HC4 is a completely different product from HC3, whereas what we are
> > discussing now is a gradual evolution.
> >
> > > So my first question is: do we want to 'break' co-location for the new
> > > version or keep it? Do we want HC Next to live next to HC 4.2?
> > >
> > > The other way to ask this is: why would you not want to co-locate v4
> and
> > > vNext.
> >
> > Co-location - i.e. allowing both to play nicely in the same
> > classloader - is only necessary if there are systems that *need* both.
> >
> > For example, JMeter uses both HC3 and HC4, but there's no reason for
> > it to use HC4 and HC4-new together.
> > JMeter will be amended as necessary to be able to use the updated API.
> >
> > > All of this leads me to think that the new HC API should be in a
> version 5
> > > with a new package name.
> >
> > Changing package name (and AID) does guarantee that the different
> > versions can co-exist.
> > However it means a lot more changes to source code.
> >
> > With gradual introduction and removal of methods it's possible to phase
> updates.
> > However, if HC5 were to both introduce useful new methods and remove
> > deprecated ones this would make the update process slightly more
> > involved.
> >
> > > From experience in a real world app server, I can testified that having
> > > Commons Lang 2 and 3 co-located is a genius feature which has avoid us
> > > countless headaches.
> >
> > As I already wrote, Commons Lang is a very different proposition.
> > Headaches (jar hell) come from having multiple independent
> > dependencies on Lang in the same classloader and not being able to
> > update them all.
> > If there is only one dependency on Lang, that could be updated without
> problems.
> >
> > If there are genuine use cases where multiple independent parts of a
> > system all depend on HC4, then yes, it might be worth striving for
> > strict binary compatibility.
> > But otherwise I think it's probably unnecessary overhead for HC4.
> >
> > As to whether the next version should be 4.x or 5.0, I don't
> particularly mind.
> > A major version bump may make sense at this point.
> >
>
> Co-location is a very valid and relevant subject. It is great that Gary
> brought it up. Luckily we do not have to make a decision about it as
> yet. HC 4.3 can be and is planned to be fully backward compatible with
> 4.2. One should be able to simply drop 4.3 release in place of 4.2 and
> still have everything working without any modification. The price of
> such backward compatibility is of course having to keep two or more
> versions of essentially the same code with some variations and a
> different class name. The benefit of this approach is that it enables
> users to migrate more gradually.
>
> I think HC4 is used widely enough to result in situations where multiple
> sub-components of the same system depend on different versions of HC4.
> Spring alone makes such situation very likely. At the same time we have
> to be realistic about our capacity to maintain deprecated functionality.
> If we can't do it right (and we cant) we will serve our users better by
> removing it. I personally think two year / two feature releases is a
> reasonable time frame to expect people to migrate off deprecated code.
> We no longer have to maintain strict binary compatibility forever just
> to please some people at Google. As long as we clearly articulate our
> policy in this regard and stick to it we will be acting responsibly
> enough given the existing project constraints.
>
I agree 100%, we should set expectations with our customers.
If we document our road map, there will be no surprises for customers. No
surprises is a 'good thing' (tm).
Customers can voice their opinion once the road map is published and this
will let us potentially adjust our plans.
It is also important to remember that no one forces anyone to upgrade to a
new version. It's a choice that has to be made by a customer.
Gary
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [DISCUSS] Deprecated code policy
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2012-11-22 at 18:40 +0000, sebb wrote:
> On 22 November 2012 18:03, Gary Gregory <ga...@gmail.com> wrote:
> > Hi all,
> >
> > <ot>
> > For US folks out there on the interwebs, Happy Thanksgving day to you
> > all. In this context, I am thankful for this community of like and
> > open-minded software gurus, tinkerers, and bit wranglers.
> > </ot>
> >
> > I find it helpful to think about this in two parts: process and labeling
> > (or what version to label code). This is my perfect version world:
> >
> > Process:
> >
> > I like to release one version N that includes @[D|d]eprecated code with a
> > comment that states the EOL policy, e.g. "This class/method will be removed
> > in version A.B" *AND* the doc MUST contain a pointer to what to do instead.
> >
> > The simplest process is to deprecate in version N and remove in the next
> > (major) version N+1, e.g. 4.2 and 5.0.
> >
> > Labeling:
> >
> > Strictly, speaking I like API breakage in "major" releases only: 4.0, 5.0,
> > 6.0 and so on. It's just simpler to think about even if it leads to
> > "version inflation". When I pick up a new major version, I know what I am
> > in for. In Commons-land, this is also an opportunity to offer co-location
> > as a feature by renaming the package from o.a.project to o.a.project2,
> > o.a.project3, and so on. This is what Commons Lang did for version 3. The
> > POM AID should also be renamed at this time.
> >
> > I would only deprecate in a minor release (4.3), not a maintenance release
> > (4.2.3). That's just because I don't expect surprises in maintenance
> > releases, I expect a maint. release to be used in a drop and go fashion
> > without deprecated warnings popping up. IOW, no new APIs in a maint release.
> >
> > HTTP Components
> >
> > How does this match up with this project? What's a good pragmatic approach?
> >
> > Well, now is a good time to talk about this since HttpClient will offer a
> > new API.
> >
> > Today I can co-locate (I'm not sure what to call this feature) HttpClient 3
> > and 4 because, this project is now a TLP and has a different package name.
>
> HC4 is a completely different product from HC3, whereas what we are
> discussing now is a gradual evolution.
>
> > So my first question is: do we want to 'break' co-location for the new
> > version or keep it? Do we want HC Next to live next to HC 4.2?
> >
> > The other way to ask this is: why would you not want to co-locate v4 and
> > vNext.
>
> Co-location - i.e. allowing both to play nicely in the same
> classloader - is only necessary if there are systems that *need* both.
>
> For example, JMeter uses both HC3 and HC4, but there's no reason for
> it to use HC4 and HC4-new together.
> JMeter will be amended as necessary to be able to use the updated API.
>
> > All of this leads me to think that the new HC API should be in a version 5
> > with a new package name.
>
> Changing package name (and AID) does guarantee that the different
> versions can co-exist.
> However it means a lot more changes to source code.
>
> With gradual introduction and removal of methods it's possible to phase updates.
> However, if HC5 were to both introduce useful new methods and remove
> deprecated ones this would make the update process slightly more
> involved.
>
> > From experience in a real world app server, I can testified that having
> > Commons Lang 2 and 3 co-located is a genius feature which has avoid us
> > countless headaches.
>
> As I already wrote, Commons Lang is a very different proposition.
> Headaches (jar hell) come from having multiple independent
> dependencies on Lang in the same classloader and not being able to
> update them all.
> If there is only one dependency on Lang, that could be updated without problems.
>
> If there are genuine use cases where multiple independent parts of a
> system all depend on HC4, then yes, it might be worth striving for
> strict binary compatibility.
> But otherwise I think it's probably unnecessary overhead for HC4.
>
> As to whether the next version should be 4.x or 5.0, I don't particularly mind.
> A major version bump may make sense at this point.
>
Co-location is a very valid and relevant subject. It is great that Gary
brought it up. Luckily we do not have to make a decision about it as
yet. HC 4.3 can be and is planned to be fully backward compatible with
4.2. One should be able to simply drop 4.3 release in place of 4.2 and
still have everything working without any modification. The price of
such backward compatibility is of course having to keep two or more
versions of essentially the same code with some variations and a
different class name. The benefit of this approach is that it enables
users to migrate more gradually.
I think HC4 is used widely enough to result in situations where multiple
sub-components of the same system depend on different versions of HC4.
Spring alone makes such situation very likely. At the same time we have
to be realistic about our capacity to maintain deprecated functionality.
If we can't do it right (and we cant) we will serve our users better by
removing it. I personally think two year / two feature releases is a
reasonable time frame to expect people to migrate off deprecated code.
We no longer have to maintain strict binary compatibility forever just
to please some people at Google. As long as we clearly articulate our
policy in this regard and stick to it we will be acting responsibly
enough given the existing project constraints.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [DISCUSS] Deprecated code policy
Posted by sebb <se...@gmail.com>.
On 22 November 2012 18:03, Gary Gregory <ga...@gmail.com> wrote:
> Hi all,
>
> <ot>
> For US folks out there on the interwebs, Happy Thanksgving day to you
> all. In this context, I am thankful for this community of like and
> open-minded software gurus, tinkerers, and bit wranglers.
> </ot>
>
> I find it helpful to think about this in two parts: process and labeling
> (or what version to label code). This is my perfect version world:
>
> Process:
>
> I like to release one version N that includes @[D|d]eprecated code with a
> comment that states the EOL policy, e.g. "This class/method will be removed
> in version A.B" *AND* the doc MUST contain a pointer to what to do instead.
>
> The simplest process is to deprecate in version N and remove in the next
> (major) version N+1, e.g. 4.2 and 5.0.
>
> Labeling:
>
> Strictly, speaking I like API breakage in "major" releases only: 4.0, 5.0,
> 6.0 and so on. It's just simpler to think about even if it leads to
> "version inflation". When I pick up a new major version, I know what I am
> in for. In Commons-land, this is also an opportunity to offer co-location
> as a feature by renaming the package from o.a.project to o.a.project2,
> o.a.project3, and so on. This is what Commons Lang did for version 3. The
> POM AID should also be renamed at this time.
>
> I would only deprecate in a minor release (4.3), not a maintenance release
> (4.2.3). That's just because I don't expect surprises in maintenance
> releases, I expect a maint. release to be used in a drop and go fashion
> without deprecated warnings popping up. IOW, no new APIs in a maint release.
>
> HTTP Components
>
> How does this match up with this project? What's a good pragmatic approach?
>
> Well, now is a good time to talk about this since HttpClient will offer a
> new API.
>
> Today I can co-locate (I'm not sure what to call this feature) HttpClient 3
> and 4 because, this project is now a TLP and has a different package name.
HC4 is a completely different product from HC3, whereas what we are
discussing now is a gradual evolution.
> So my first question is: do we want to 'break' co-location for the new
> version or keep it? Do we want HC Next to live next to HC 4.2?
>
> The other way to ask this is: why would you not want to co-locate v4 and
> vNext.
Co-location - i.e. allowing both to play nicely in the same
classloader - is only necessary if there are systems that *need* both.
For example, JMeter uses both HC3 and HC4, but there's no reason for
it to use HC4 and HC4-new together.
JMeter will be amended as necessary to be able to use the updated API.
> All of this leads me to think that the new HC API should be in a version 5
> with a new package name.
Changing package name (and AID) does guarantee that the different
versions can co-exist.
However it means a lot more changes to source code.
With gradual introduction and removal of methods it's possible to phase updates.
However, if HC5 were to both introduce useful new methods and remove
deprecated ones this would make the update process slightly more
involved.
> From experience in a real world app server, I can testified that having
> Commons Lang 2 and 3 co-located is a genius feature which has avoid us
> countless headaches.
As I already wrote, Commons Lang is a very different proposition.
Headaches (jar hell) come from having multiple independent
dependencies on Lang in the same classloader and not being able to
update them all.
If there is only one dependency on Lang, that could be updated without problems.
If there are genuine use cases where multiple independent parts of a
system all depend on HC4, then yes, it might be worth striving for
strict binary compatibility.
But otherwise I think it's probably unnecessary overhead for HC4.
As to whether the next version should be 4.x or 5.0, I don't particularly mind.
A major version bump may make sense at this point.
> Gobble, Gobble,
> Gary
>
>
> On Thu, Nov 22, 2012 at 9:27 AM, sebb <se...@gmail.com> wrote:
>
>> On 22 November 2012 13:46, Oleg Kalnichevski <ol...@apache.org> wrote:
>> > Folks
>> >
>> > There are lots of changes planned for the 4.3 series that will require
>> > many of the old implementation classes to be deprecated in favor of
>> > newer ones with a different API. While the amount of deprecated code
>> > will be moderate in HttpCore there will be LOTS of it in HttpClient. We
>> > should start thinking how we want to go about deprecated code in the 4.x
>> > code line.
>> >
>> > (1) We could keep deprecated functionality indefinitely to maximize
>> > compatibility. In this case we should start thinking about 5.0 and API
>> > incompatible changes soonish as we have already accumulated quite a lot
>> > of deprecated legacy code.
>> >
>> > (2) Alternatively, we could be selectively removing deprecated code
>> > after a certain number of feature releases (two feature releases) and a
>> > certain grace period (approximately two years) and keep 5.0 for some
>> > really major changes such as HTTP/2.0 or HTTP/1.1bis. By the way, this
>> > is what we have done about stuff deprecated in 4.0 GA.
>> >
>> > I am leaning more towards option 2 and therefore would like to proceed
>> > with removal of code deprecated in the 4.1 release from the 4.3 branch
>> > (both HttpCore and HttpClient).
>> >
>> > What are your thoughts? What would be your preference?
>>
>> Option 2 breaks binary compatibility, so is not suitable for all
>> libraries (e.g. it would not be suitable for Commons components, which
>> are likely to be referenced multiple times in the same classpath).
>>
>> However, in the case of HC, it seems very unlikely that a single
>> classpath will contain multiple independent dependencies on HC.
>>
>> So Option 2 seems the best way forward in this case.
>>
>> > Oleg
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> > For additional commands, e-mail: dev-help@hc.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [DISCUSS] Deprecated code policy
Posted by Gary Gregory <ga...@gmail.com>.
Hi all,
<ot>
For US folks out there on the interwebs, Happy Thanksgving day to you
all. In this context, I am thankful for this community of like and
open-minded software gurus, tinkerers, and bit wranglers.
</ot>
I find it helpful to think about this in two parts: process and labeling
(or what version to label code). This is my perfect version world:
Process:
I like to release one version N that includes @[D|d]eprecated code with a
comment that states the EOL policy, e.g. "This class/method will be removed
in version A.B" *AND* the doc MUST contain a pointer to what to do instead.
The simplest process is to deprecate in version N and remove in the next
(major) version N+1, e.g. 4.2 and 5.0.
Labeling:
Strictly, speaking I like API breakage in "major" releases only: 4.0, 5.0,
6.0 and so on. It's just simpler to think about even if it leads to
"version inflation". When I pick up a new major version, I know what I am
in for. In Commons-land, this is also an opportunity to offer co-location
as a feature by renaming the package from o.a.project to o.a.project2,
o.a.project3, and so on. This is what Commons Lang did for version 3. The
POM AID should also be renamed at this time.
I would only deprecate in a minor release (4.3), not a maintenance release
(4.2.3). That's just because I don't expect surprises in maintenance
releases, I expect a maint. release to be used in a drop and go fashion
without deprecated warnings popping up. IOW, no new APIs in a maint release.
HTTP Components
How does this match up with this project? What's a good pragmatic approach?
Well, now is a good time to talk about this since HttpClient will offer a
new API.
Today I can co-locate (I'm not sure what to call this feature) HttpClient 3
and 4 because, this project is now a TLP and has a different package name.
So my first question is: do we want to 'break' co-location for the new
version or keep it? Do we want HC Next to live next to HC 4.2?
The other way to ask this is: why would you not want to co-locate v4 and
vNext.
All of this leads me to think that the new HC API should be in a version 5
with a new package name.
>From experience in a real world app server, I can testified that having
Commons Lang 2 and 3 co-located is a genius feature which has avoid us
countless headaches.
Gobble, Gobble,
Gary
On Thu, Nov 22, 2012 at 9:27 AM, sebb <se...@gmail.com> wrote:
> On 22 November 2012 13:46, Oleg Kalnichevski <ol...@apache.org> wrote:
> > Folks
> >
> > There are lots of changes planned for the 4.3 series that will require
> > many of the old implementation classes to be deprecated in favor of
> > newer ones with a different API. While the amount of deprecated code
> > will be moderate in HttpCore there will be LOTS of it in HttpClient. We
> > should start thinking how we want to go about deprecated code in the 4.x
> > code line.
> >
> > (1) We could keep deprecated functionality indefinitely to maximize
> > compatibility. In this case we should start thinking about 5.0 and API
> > incompatible changes soonish as we have already accumulated quite a lot
> > of deprecated legacy code.
> >
> > (2) Alternatively, we could be selectively removing deprecated code
> > after a certain number of feature releases (two feature releases) and a
> > certain grace period (approximately two years) and keep 5.0 for some
> > really major changes such as HTTP/2.0 or HTTP/1.1bis. By the way, this
> > is what we have done about stuff deprecated in 4.0 GA.
> >
> > I am leaning more towards option 2 and therefore would like to proceed
> > with removal of code deprecated in the 4.1 release from the 4.3 branch
> > (both HttpCore and HttpClient).
> >
> > What are your thoughts? What would be your preference?
>
> Option 2 breaks binary compatibility, so is not suitable for all
> libraries (e.g. it would not be suitable for Commons components, which
> are likely to be referenced multiple times in the same classpath).
>
> However, in the case of HC, it seems very unlikely that a single
> classpath will contain multiple independent dependencies on HC.
>
> So Option 2 seems the best way forward in this case.
>
> > Oleg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [DISCUSS] Deprecated code policy
Posted by sebb <se...@gmail.com>.
On 22 November 2012 13:46, Oleg Kalnichevski <ol...@apache.org> wrote:
> Folks
>
> There are lots of changes planned for the 4.3 series that will require
> many of the old implementation classes to be deprecated in favor of
> newer ones with a different API. While the amount of deprecated code
> will be moderate in HttpCore there will be LOTS of it in HttpClient. We
> should start thinking how we want to go about deprecated code in the 4.x
> code line.
>
> (1) We could keep deprecated functionality indefinitely to maximize
> compatibility. In this case we should start thinking about 5.0 and API
> incompatible changes soonish as we have already accumulated quite a lot
> of deprecated legacy code.
>
> (2) Alternatively, we could be selectively removing deprecated code
> after a certain number of feature releases (two feature releases) and a
> certain grace period (approximately two years) and keep 5.0 for some
> really major changes such as HTTP/2.0 or HTTP/1.1bis. By the way, this
> is what we have done about stuff deprecated in 4.0 GA.
>
> I am leaning more towards option 2 and therefore would like to proceed
> with removal of code deprecated in the 4.1 release from the 4.3 branch
> (both HttpCore and HttpClient).
>
> What are your thoughts? What would be your preference?
Option 2 breaks binary compatibility, so is not suitable for all
libraries (e.g. it would not be suitable for Commons components, which
are likely to be referenced multiple times in the same classpath).
However, in the case of HC, it seems very unlikely that a single
classpath will contain multiple independent dependencies on HC.
So Option 2 seems the best way forward in this case.
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org