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. 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...] Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
