commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From luc.maison...@free.fr
Subject Re: [math] 2.2 compatibility issues
Date Tue, 25 Jan 2011 17:25:42 GMT
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.

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

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

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

I guess we really should have 2.2 out as soon as possible and focus our work
on 3.0 to get it as stable as possible before publishing it. With 2.2 out,
many users will have available some important bug fixes and this will buy
us some time for 3.0, in case it needs a few more months to finish.

best regards,
Luc

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

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


Mime
View raw message