Eric, I find it hard to disagree with you, being a fan of incremental, iterative development myself. I just regret all the energy and time that went into 2.0 API compatibility workarounds so far. If we go with 3.0 then I would like to see a few more 2.0 API breakages that had been turned down for the sake of maintaining 2.0 compatibility, especially in the exception handling framework. I would also suggest HttpMethod interface be completely gotten rid of and the abstract HttpMethodBase renamed to HttpMethod.
Oleg -----Original Message----- From: Eric Johnson [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 14:53 To: Commons HttpClient Project Subject: Re: Next Release? What about next release version number? Oleg, I understand your thinking, but my thinking it is that it is far more important to release new stable releases often, rather than worrying about their version number. Re-exposing my bias, I strongly prefer incremental change. With many compliments to the incredible work that has gone into the next release so far (the presumed 2.1, now 3.0?), I don't see any reason to hesitate calling it 3.0. At the same time, I don't think that means that we should consider jumping on radical changes beyond what has been done already. The version number tells me that it is not going to be a drop-in compatible change, but the small number of API changes is actually a good thing, in that clients can migrate quickly. My previous comment was there only to prod for consideration of low impact changes that might make it easier to maintain HttpClient moving forward. For example, the one change that occurs to me - get rid of the illusion (delusion?) that clients could *ever* successfully implement the HttpMethod interface. Perhaps deprecate the interface, and override it with an abstract base class, which clients would be expected to override instead. This isn't a huge change, and adds no additional functionality, but adds a lot of flexibility for enabling backward compatible enhancements. -Eric. Kalnichevski, Oleg wrote: >>Thinking about it as a 3.0 release, though, I think we should make an >>effort to change the 3.0 API so that we're more confident of our ability >>to make critical incremental changes. >> >> > >I hate revisiting the same discussions that raged on this forum 6 months ago, but >this is exactly the point. If we decide to go 3.0, then we should stop playing 'bend >2.0 API around' kind of games and should get down to some serious work (which would >inevitably delay the next stable by maaaaaany months, if not years, judging by our >current rate of progress) > >Oleg > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
