Roland et al,
HttpAsync (as well as HttpNI) represents a completely new code line so
far untested in the real life applications. I believe the first release
version should be 1.0 not 4.0 reflecting this fact.
What do you think?
To unsubscribe, e-mail: httpclient-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: httpclient-dev-help (AT) jakarta (DOT) apache.org

Hi ,

HttpAsync (as well as HttpNI) represents a completely new code line so
far untested in the real life applications. I believe the first release
version should be 1.0 not 4.0 reflecting this fact.

What do you think?

I thought about that for a second or two, then chose the same version
number as for HttpCore. Mainly because that's what my employer is doing
with it's products :-) I thought it would be less confusing for users to
combine the "4.0" versions of all HttpComponents. But we'll have
dependencies on minor versions anyway, so maybe it won't be that much
of a difference.

I guess the ultimate question will be how we're going to present the
whole range of HttpComponents to the user. I've refrained from asking
that question so far, because I see other priorities for the time being.

I have no problem with labelling HttpAsync 1.0.

cheers,
Roland

To unsubscribe, e-mail: httpclient-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: httpclient-dev-help (AT) jakarta (DOT) apache.org

Sun, 2006-06-25 at 17:16 +0200, Roland Weber wrote:
Hi ,

HttpAsync (as well as HttpNI) represents a completely new code line so
far untested in the real life applications. I believe the first release
version should be 1.0 not 4.0 reflecting this fact.

What do you think?

I thought about that for a second or two, then chose the same version
number as for HttpCore. Mainly because that's what my employer is doing
with it's products :-) I thought it would be less confusing for users to
combine the "4.0" versions of all HttpComponents. But we'll have
dependencies on minor versions anyway, so maybe it won't be that much
of a difference.

I guess the ultimate question will be how we're going to present the
whole range of HttpComponents to the user. I've refrained from asking
that question so far, because I see other priorities for the time being.

To me it all boils down to a simple question whether we want to ship a
full bundle comprised of all HttpComponent modules
(httpcomponents-full.jar) and if so how we are going to version it.
, the versioning scheme of individual modules does not seem
like a big deal.

I have no problem with labelling HttpAsync 1.0.

cheers,
Roland

To unsubscribe, e-mail: httpclient-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: httpclient-dev-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: httpclient-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: httpclient-dev-help (AT) jakarta (DOT) apache.org

Sun, 2006-06-25 at 10:34 -0700, Michael Becke wrote:
To me it all boils down to a simple question whether we want to ship a
full bundle comprised of all HttpComponent modules
(httpcomponents-full.jar) and if so how we are going to version it.
, the versioning scheme of individual modules does not seem
like a big deal.

Agreed. That is the big question. Individual modules, if we release
them, should probably be numbered starting at 1. If we're releasing
HttpComponents as a replacement for HttpClient it should be 4. We may
have to wait until the pieces are more compete and we have more users
of the codebase to decide.

Mike

Mike, Roland et al

Here's my Evil (TM) Plan

I am working hard trying to complete the rewrite of HttpCookie. I also
would like to copy over HttpAuth and HttpConn code from the Commons
HttpClient branch to HttpComponents HttpClient at some point in July.
Both HttpAuth and HttpConn may require very little API changes beyond
trivial removal of deprecated methods. When that's done we will have a
pretty complete set of components required to build a full fledged HTTP
client: HttpCore, HttpCookie, HttpAuth and HttpConn. That would be the
right moment to step back a little and take a closer look at our
options:

(1) Do we want HttpCookie, HttpAuth, HttpConn to share the same release
cycle as HttpClient and be released under the same version? In this case
httpcomponents-full.jar may never be needed

(2) Do we want to go all the way and spin off HttpCookie, HttpAuth,
HttpConn into separate modules with a separate release cycle versioned
independently from HttpClient? If so, how we are going to serve the
needs of those users who have never felt there were any particular
problem with HttpClient monolithic design or its package size? Those
people may be very upset at having to download a whole bunch of tiny
jars with different versions instead of just one.

(2.1) Do we want to release jakarta-httpclient-4.x consisting of all its
HttpComponent dependencies: HttpCore, HttpCookie, HttpAuth, HttpConn?
How do we version it?

(2.2) Do we want to release jakarta-httpcomponents-4.x consisting of all
HttpComponent modules including HttpClient? How do we version it?

There is still plenty of time to think these options over.

Cheers,

To unsubscribe, e-mail: httpclient-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: httpclient-dev-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: httpclient-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: httpclient-dev-help (AT) jakarta (DOT) apache.org

To me it all boils down to a simple question whether we want to ship a
full bundle comprised of all HttpComponent modules
(httpcomponents-full.jar) and if so how we are going to version it.
, the versioning scheme of individual modules does not seem
like a big deal.

Agreed. That is the big question. Individual modules, if we release
them, should probably be numbered starting at 1. If we're releasing
HttpComponents as a replacement for HttpClient it should be 4. We may
have to wait until the pieces are more compete and we have more users
of the codebase to decide.

Mike

To unsubscribe, e-mail: httpclient-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: httpclient-dev-help (AT) jakarta (DOT) apache.org

Hi ,

I am working hard trying to complete the rewrite of HttpCookie. I also
would like to copy over HttpAuth and HttpConn code from the Commons
HttpClient branch to HttpComponents HttpClient at some point in July.
Both HttpAuth and HttpConn may require very little API changes beyond
trivial removal of deprecated methods. When that's done we will have a
pretty complete set of components required to build a full fledged HTTP
client: HttpCore, HttpCookie, HttpAuth and HttpConn.

Sounds way cool! Thanks for all the hard work, while we are
spending our time in the sun or at lakes :-)

Here are my 0.02 on the options:

That would be the
right moment to step back a little and take a closer look at our
options:

(1) Do we want HttpCookie, HttpAuth, HttpConn to share the same release
cycle as HttpClient and be released under the same version? In this case
httpcomponents-full.jar may never be needed

(2) Do we want to go all the way and spin off HttpCookie, HttpAuth,
HttpConn into separate modules with a separate release cycle versioned
independently from HttpClient?

I am still in favor of spinning them off, after one or two combined
alphas to stabilize the API. the API is stable we don't expect
many changes, so the additional effort will be low. I therefore do
not see a reason to revise the initial plan.

If so, how we are going to serve the
needs of those users who have never felt there were any particular
problem with HttpClient monolithic design or its package size? Those
people may be very upset at having to download a whole bunch of tiny
jars with different versions instead of just one.

(2.1) Do we want to release jakarta-httpclient-4.x consisting of all its
HttpComponent dependencies: HttpCore, HttpCookie, HttpAuth, HttpConn?
How do we version it?

Rather not. I don't see a point in stopping halfway along the road.

(2.2) Do we want to release jakarta-httpcomponents-4.x consisting of all
HttpComponent modules including HttpClient?

Yepp.

How do we version it?

The idea I was pondering is to use the HttpComponents meta-distribution
as the version counter. Say we have HttpComponents version 4.0.0 with
HttpCore, HttpClient, HttpAuth, HttpCookie, HttpConn all at the same
version. Then HttpConn needs an update. Combined version goes up to
4.0.1, which is also used for HttpConn. All others stay at 4.0.0.
Then HttpClient needs an update, which requires an update of HttpCore.
Combined version goes to 4.0.2, which is also used for HttpCore and
HttpClient, both skipping 4.0.1. All others stay where they are.
The release cycle for HttpComponents will always be locked with the
release cycle of the component or components that trigger the update.

I haven't thought this through to the end. I suspect that alpha/beta
will not be a problem: Components alpha packages the newest versions
of all components, including alpha versions. Components beta packages
the newest versions of all components that have reached beta stage.
Components final packages only final versions of all components.

What could break this strategy is upgrades in the second digit. If
HttpClient is supposed to go to 4.1, then HttpComponents would need
to go to 4.1. Then even minor upgrades to any other package would
need that package to upgrade to a 4.1.x level. the other hand, we
might just count all HttpComponents releases in the third digit and
not re-set that when the second digit changes. So if the version is
4.0.9 and we want to upgrade to 4.1, we'd have 4.1.10. else we
count the HttpComponents version with a dash: 4.0-29, 4.1-30 and
attach the dash version to the components that triggered the updated.

No matter what, we'd need a big table on the HttpComponents site
which lists for every release of HttpComponents exactly what versions
of the individual components are in there.

As I said, I didn't think it through. But despite the versioning
question, I am in favor of releasing individual components as well
as a combined package, which should include HttpNI and HttpAsync.
, the communities around these might have an even harder
time to grow. Packaging everything should encourage people that use
the combined JAR to try out those APIs, rather than avoiding them
in order to not catch a new dependency.

I'll be leaving for a short business trip this evening.
I should be back on Thursday to resume the discussion.

cheers,
Roland

To unsubscribe, e-mail: httpclient-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: httpclient-dev-help (AT) jakarta (DOT) apache.org