On Tue, Jan 25, 2011 at 9:54 AM, Gilles Sadowski <gil...@harfang.homelinux.org> 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. Phil > > > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
