commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [math] 2.2 compatibility issues
Date Tue, 25 Jan 2011 14:54:41 GMT

> >> >> 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.

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.

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)...

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


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

View raw message