commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] 2.2 compatibility issues
Date Tue, 25 Jan 2011 15:01:25 GMT
On Tue, Jan 25, 2011 at 9:54 AM, Gilles Sadowski
<> wrote:
> Phil,
>> >> >> I guess there are some other logical alternatives to consider:
>> >> >>
>> >> >> 1) s/2.2/3.0  s/3.0/4.0
>> >> >> 2) abandon 2.2 release
>> >
>> > From the fact that you have to consider these options, let's remember that,
>> > at the release of 3.0, we should immediately create a "bug-fix-only" branch
>> > (destined to remain backward compatible).
>> >
>> If what you mean by this is that immediately after 3.0 we start
>> introducing incompatible changes (against the released 3.0 API), then
>> no.  We need to stabilize our API.  We should try *very hard* to get
>> the compatiblity-breaking changes that we want to introduce into 3.0
>> and then proceed with 3.1, 3.2, etc. that are compatible with the 3.0
>> release.  It is not manageable or fair to users to bump major release
>> numbers with each release, nor is it consistent with how we manage
>> components in Commons.
> I don't mean to start a discussion about what we need/could/should/must do.
> I'm just referring to the recent history: How messy it is (to the point that
> you proposed abandoning release 2.2) to decide for a backward-compatible
> release *after* incompatible changes have already been introduced.

That will not happen again.  I will veto backward-incompatible changes
in trunk from 3.0 onwards.

> Incompatible changes might be necessary to continue developing CM: From what
> I recall, one person (not me, the future contributor of the CMA-ES algorithm)
> already proposed new features.
Our task is to try as best we can to "future proof" the API via good,
forward-thinking design and find ways to implement new functionality
in a compatible way.  Other Commons components have been doing this
for 9+ years now and [math] is no different.

> So, to be clearer, I should have written:
> As soon as incompatible changes are proposed in "trunk", we should create a
> "bug-fix-only" branch (in case bugs are discovered and fixed before the new
> major release is ready)...

No, we should first try to find a way to get the enhancements in in a
compatible way.  If not, that means we made mistakes (again) in 3.0
and need to discuss starting 4.0.

> [In fact, it is a proposal to spare you the tedious work of "reverting" the
> incompatibilities after the fact...]

The way to avoid that is to think deeply about the 3.0 API, get it
right and introduce enhancements in a compatible way.  That is our
responsibility to our users.

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

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

View raw message