commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [net] binary compatibility be damned
Date Mon, 18 Apr 2011 20:26:10 GMT
On 18 April 2011 21:03, Daniel F. Savarese <> wrote:
> In message <>, sebb writes:
>>If binary compat. is to be broken, then it needs to be done once, and
>>done properly so it does not have to be done again. That's not
>>something I personally have any inclination to tackle at present, so
>>I'm trying to ensure binary compat. whilst fixing as many of the bugs
>>as possible.
> Okay, fine.  I disagree with the level of importance you're placing on
> binary compatibility as it places extreme limits on the ability of a code
> base to evolve for the better over time.

I agree it limits possible changes, but the limitations may not be as
bad as you imply.
For example it was possible to rewrite NNTP to use long instead of int
and still retain binary compat.

Breaking binary compat is very disruptive for downstream users; for
many (most?) Commons components it should be considered equivalent to
releasing a brand new component.

> Given that I've long advocated
> a Commons Net rewrite, I can buy into the extrapolated argument that if
> we're going to redesign Commons Net, let's do it properly from the
> ground up.


> Since now is obviously not the right time to do that (as it
> would greatly delay a new release), I won't stir up the pot any further.
> However, if we're going to continue to live with warts and make ad-hoc
> workarounds in the interest of preserving binary compatibility, can we
> agree to not make any changes that break run-time compatibility (i.e.,
> changes like POP3.setState, which as far as I know was the only such
> change) except in the case of actual bug fixes or functionality
> enhancements?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message