Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Tue, 25 Jan 2011 16:51:41 +0100
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: dev@commons.apache.org
Subject: Re: [math] 2.2 compatibility issues
Message-ID: <20110125155141.GH22814@dusk.harfang.homelinux.org>
Mail-Followup-To: dev@commons.apache.org
References: <AANLkTikb+gY=6vqkpoq=sfAt5rkpHkhdN_YtzxxPFbca@mail.gmail.com>
 <1259953915.332591295885065568.JavaMail.root@spooler6-g27.priv.proxad.net>
 <AANLkTim+odBjrQDY_qheu43USc_jXiX4Ck-dO3Ua+ex_@mail.gmail.com>
 <20110125125642.GB22814@dusk.harfang.homelinux.org>
 <AANLkTi=H1VqNc95Mz0OtfifP3EPPi=+5pruT=Dq9-j3O@mail.gmail.com>
 <20110125145441.GF22814@dusk.harfang.homelinux.org>
 <AANLkTikinUZdMgek2X6=Wge76gtC8wo8RRXhuhr_zo7u@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <AANLkTikinUZdMgek2X6=Wge76gtC8wo8RRXhuhr_zo7u@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)

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

???
Do you really think CM development is finished? If not, how can you affirm
that the design is final?


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

"as best" --> _not_ "future-proof".
I sure that Luc and you and the others had good, forward-thinking, ideas
also prior to release 2.1. Still I had others maybe also good
forward-thinking design ideas after 2.1 and so we started developing
an incompatible upgrade.
We cannot think about everything before release 3.0.

I'm not sure that CM is no different than other Commons components, it's
scope is not as easily limited as, say, a "Collection" interface for
primitive types.

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

I didn't say anything else.

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

That's what we did, I think; that certainly doesn't imply that we thought
thoroughly... [I certainly think that it's a safer bet to say that we didn't
than otherwise ;-).]


Best regards,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org