RE: cvs commit:
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient
HttpClient.java HttpMethod.java HttpMethodBase.java> IMHO the concept of a
commons is DOA unless external
> interfaces are viewed as contracts.
Right. For *released* versions of components. Stuff that's in development
is, well, in development.
Rodney, you have to consider that this is released code, in the context of
its interaction with Slide.
> For that reason, I would suggest that jakarta-commons
> is the place for the STABLE version.
I don't see any reason for one to assume that the latest CVS version of
*anything* is going to be stable. If things aren't changing, why do we need
to version code? If you want stable, use the binaries, or pick an instant
in time and tag it.
That is why you should have NOT blocked the release, so that Slide could
have used the 1.0 release as a stabel point and not rely upon the CVS. I am
saddened to see that not only did Slide change the API which affected me as
an early adopter, but now httpclient is changing, which is affecting Slide,
which is in turn affecting me. Sorry for the rant, but is does have to stop
somewhere.
Can we just release even a 0.90 based upon last week? That would seem to
help everyone out. It is not a 1.0, but is is a stable release, IMHO.
> Those that wish to make speculative changes
> are free to fork, and may even consider using
> the sandbox to do so.
Distinguish "speculative changes" from regular development?
Why are we holding an *unreleased* commons component to a higher standard of
stability than anything else? Once a release is made, API contracts start
to matter. Before that, commit-then-review seems like the precedent.
It seems strange to me that Dirk and I were the main participants in the
specific interaction that spawned this thread, and yet we're the least
worked up about it.
No one is 'worked up' about it, just merely trying to show their viewpoints.
Scott
