commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [math] 2.2 compatibility issues
Date Tue, 25 Jan 2011 18:07:18 GMT
On Tue, Jan 25, 2011 at 12:25 PM,  <luc.maisonobe@free.fr> wrote:
> Hi Gilles,
>
> ----- "Gilles Sadowski" <gilles@harfang.homelinux.org> a écrit :
>
>> > >> >> >> 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?
>
> I don't think this is what Phil meant. What is important is once 3.0 is out,
> no incompatible changes will be introduced in the 3.X series. Incompatible
> changes will be postponed to a 4.0 version and so on.
>
> This is simply restating what we have always tried to do: dot releases must
> be compatible, major releases are allowed to break compatibility.
>
Yes, exactly.   To be perfectly clear, until we have agreed to begin
4.0 development and the pom version number in trunk has been
incremented to 4.0,  I am going to veto backward-incompatible changes
once the 3.0 release is out.  We have a great opportunity now - like
the one that we had in the runup to 2.0 - to fix the sins of the past
and arrive at a public API that we can stand behind and our users can
expect stability in for some years to come.
>>
>>
>> > > 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.
>
> We are all aware of this.
>
Yes, but we can certainly think about making changes / improvements
that will enable capabilities to be added and even the API to evolve
without breaking backward compatibility.
>>
>> 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.
>
> I am sure their are many different use cases for each Commons components,
> and many incompatible solutions, trials and errors.
>
> Commons Math topic (mathematics) is perhaps not as widespread in Apache world
> than global web, databases, networking or computer science in general, but it
> could still follow the same global rules. These rules are answers to users
> needs about stability, reliability, trust and these needs are the same irrespective
> of the topic.
>
+1
Phil
>>
>> >

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


Mime
View raw message