On Tue, Jan 25, 2011 at 12:25 PM, <luc.maison...@free.fr> wrote: > Hi Gilles, > > ----- "Gilles Sadowski" <gil...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
