+1
Michael Becke wrote:
I propose that we start using commons-codec (nightly builds) for our
Base64 and URL encoding needs. This change would go into effect for
the 2.1 release (HEAD).
--
Vote: commons-codec depende
other than bugfixes -- should
any be required! -- on 2.0).
- Chris
- Original Message -
From: "Michael Becke" <[EMAIL PROTECTED]>
To: "Commons HttpClient Project" <[EMAIL PROTECTED]>
Sent: Thursday, July 17, 2003 3:21 AM
Subject: Re: [VOTE] Add commons-codec as a
Not really. I am still fully behind the 2.1 release plan (as long as it
remains about 'doing 2.0 more or less right', and not about second
attempt at trying to work around the existing design limitations).
However, if the pressure mounts to strictly follow the Jakarta release
guidelines, I will str
> Well said. The 2.0 release is really not what any of us wanted. I was
> also looking to 2.1 as the first release 'done more or less right'. I
> think we can still accomplish this. We may just have to ignore the
> official guidelines for what constitutes a minor release.
>
> It sounds lik
My initial idea was we would bend the release guidelines somewhat for
2.1 release. 2.1 would be in essence '2.0 done more or less right'.
We would have to do some selective and limited API changes but would
retain the overall conceptual compatibility. Nothing truly radical
and ground breaking. Sinc
> I guess you are right. It is mostly a case of semantics. What exactly
> do we mean by 2.1? The official description of a minor release does not
> really fit with our plans (which I still agree with). I do not think a
> 3.0 release is quite appropriate either though. Is there a middle
> g
Kalnichevski, Oleg wrote:
It may be too a strong opinion, but I am convinced 2.0 API is not
worth a single hour of further development beyond bug fixes. I will
also strongly object any cross-site redirect fix at the expense of
overall quality. I think we have spent enough time already coming up
wit
Kalnichevski, Oleg wrote:
If it is just about release numbers, let us call it HttpClient 3.0
Amen. I'm not sure how much point there is in a 2.1 release if there's
not allowed to be *any* API breakage. Maybe we should freeze the 2.0
stream and just put out 2.0.1, etc. bug fix releases and cal
Christopher Lenz wrote:
just a "we'll try to preserve backwards compatibility as much as possible".
May I remind everybody that we made the 2.0 branch so that we can
finally overhaul the architecture. This normally implies large scale API
changes. Maintaining backwards compatibility and doing rea
Kalnichevski, Oleg wrote:
True, but neither has HttpClient 2.1:) We will most likely have to put
some effort into getting a final codec release that contains this code.
I agree, adding a jar could be considered an API break, but it was part
of our plan for 2.1. The only real API changes that t
tever, but I finally want to be
able to do things right
Oleg
-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 16:26
To: Commons HttpClient Project
Subject: Re: [VOTE] Add commons-codec as an HttpClient dependency
Kalnichevski, Oleg wrote:
&g
Kalnichevski, Oleg wrote:
Right, but the problem is those folks who use CVS snapshots while
insisting on complete (maximum) API compatibility with 2.0 branch.
They have not been quite receptive to 'but it was part of our plan
for 2.1' kind of arguments up to now.
Of course, I can put up the same 'E
That's not a bad idea, but I would definitely like to avoid having any
more than one officially sanctioned jar file. It's quite simple for
people to build their own uber-jar if needed.
Personally, I don't see any problem with adding a dependency for 2.1.
If anyone does have an issue with this
Kalnichevski, Oleg wrote:
Right, but the problem is those folks who use CVS snapshots while insisting on complete (maximum) API compatibility with 2.0 branch. They have not been quite receptive to 'but it was part of our plan for 2.1' kind of arguments up to now.
Of course, I can put up the same
> True, but neither has HttpClient 2.1:) We will most likely have to put
> some effort into getting a final codec release that contains this code.
> I agree, adding a jar could be considered an API break, but it was part
> of our plan for 2.1. The only real API changes that this requires is
>
On Wednesday, July 16, 2003, at 05:38 AM, Kalnichevski, Oleg wrote:
I have a few concerns, though:
1.) URLCodec that we should be using has not been officially released
yet
True, but neither has HttpClient 2.1:) We will most likely have to put
some effort into getting a final codec release that
HttpClient
source tree for the 2.1 release. Does anyone see any downsides to that I may be
missing?
Oleg
-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 04:20
To: Commons Project
Subject: [VOTE] Add commons-codec as an HttpClient dependency
I
Kalnichevski, Oleg wrote:
Because only two are really worth remebering (Base64 & URLCodec) as far as we are concerned ;-) (At least for now)
Oleg
Sure. I mean, all I want to say is, Adrian this is a good idea and
thanks for volunteering.
Odi
--
mons-codec as an HttpClient dependency
oops, true. No idea why I remembered only two classes...
Kalnichevski, Oleg wrote:
> Odi,
> I do not think it is quite correct. There's now at least two dozens of files, and
> some of them are really of marginal use (language and phonetic encoder
oops, true. No idea why I remembered only two classes...
Kalnichevski, Oleg wrote:
Odi,
I do not think it is quite correct. There's now at least two dozens of files, and some
of them are really of marginal use (language and phonetic encoders, for instance)
Oleg
Packages always seem to get bigger - something about people wanting new
functionality all the time... :)
I'm actually keen to start a policy of very exact (but unofficial)
dependency listings for those scungy folks like me. :) For instance if
we add lang as a dependency I'd definitely be cutti
46
To: Commons HttpClient Project
Subject: Re: [VOTE] Add commons-codec as an HttpClient dependency
Adrian Sutton wrote:
> +1.
>
> Also +1 for keeping a specific list of files that's required from codec
> so that applet developers like me can just pull them out instead of
>
Adrian Sutton wrote:
+1.
Also +1 for keeping a specific list of files that's required from codec
so that applet developers like me can just pull them out instead of
having the whole kit and kaboodle. I volunteer for such a role.
Adrian Sutton.
Currently Codec consists of 2 (two) classes, Ad
+1.
Also +1 for keeping a specific list of files that's required from codec
so that applet developers like me can just pull them out instead of
having the whole kit and kaboodle. I volunteer for such a role.
Adrian Sutton.
On Wednesday, July 16, 2003, at 05:05 PM, Ortwin Glück wrote:
+1
+1
Michael Becke wrote:
I propose that we start using commons-codec (nightly builds) for our
Base64 and URL encoding needs. This change would go into effect for
the 2.1 release (HEAD).
--
Vote: commons-codec dependen
+1
On Tuesday, July 15, 2003, at 10:20 PM, Michael Becke wrote:
I propose that we start using commons-codec (nightly builds) for our
Base64 and URL encoding needs. This change would go into effect for
the 2.1 release (HEAD).
--
I propose that we start using commons-codec (nightly builds) for our
Base64 and URL encoding needs. This change would go into effect for
the 2.1 release (HEAD).
--
Vote: commons-codec dependency for 2.1
[ ] +1 I am i
27 matches
Mail list logo
