On 11/6/15 2:04 AM, luc wrote: > Le 2015-11-06 02:34, Gilles a écrit : >> On Thu, 5 Nov 2015 15:41:57 -0700, Phil Steitz wrote: >>> On 11/5/15 1:58 PM, Luc Maisonobe wrote: >>>> Le 05/11/2015 12:25, Gilles a écrit : >>>>> Hello. >>>>> >>>>> On Wed, 04 Nov 2015 10:13:00 +0100, luc wrote: >>>>>> Hi all, >>>>>> >>>>>> I would like to release 3.6 in the upcoming weeks. >>>>>> There have been a bunch of bug fixes and a few evolutions >>>>>> that are >>>>>> important to me. >>>>> s/3.6/4.0/ >>>>> >>>>> And the statement is still true. >>>>> >>>>>> [...] >>>>>> >>>>>> Of course, once 3.6 is out the MATH_3_X branch will remain >>>>>> alive and >>>>>> we could also release other versions later on in the 3.x series. >>>>> Should we worry that the next major release will be endlessly >>>>> delayed? >>>> I think we are really quite far from releasing 4.0 as in many >>>> packages >>>> we did not even start refactoring API. Optimization is clearly >>>> the most >>>> well known example, but there are also other things waiting in >>>> the pipe >>>> for geometry and ode. >> >> Is there any specific target for 4.0? > > Yes, at least having changed public API. > >> Could we judge how far we are from releasing a major release with >> the >> same arguments which you used for 3.6 (many additions, bug fixes, >> things someone would like to use, etc.)? >> >> 4.0 does not need to be perfect. [3.0 was supposed to be perfect >> ;-).] >> 4.1 will be! Or 4.2, or 5.0... > > 4.x for x > 1 will have exactly the same problems as 4.0 API-wise > since > once 4.0 is out the API will be fixed. > >> >> Let's not forget that we agreed to work towards 4.0, and that the >> 3.x >> branch was an afterthought. > > I agree and was slightly reluctant to continue on 3.X at that > time. Deciding > to still keep this branch was indeed a good idea. I properly > address the problem > that we did not find time to work on 4.0 as we wanted. > >> >> Since we now effectively maintain two versions of CM, it makes sense >> to allow people to benefit from the extra work. > > Yes, but our own overzealous rule about compatibility (I can take the > blame here, I am guilty for this) induces that we change API only > when > major versions are published. We do have the opportunity to do > this for > 4.0, lets use it at least and not again postpone needed changes. > Our 3.X > API sucks in many places and we know it. > >> >> My viewpoint is that we can have releases from both branches, making >> it clear what is old/deprecated/broken in 3.x and what is still >> missing in 4.y. > > If it were only missing features, that can be added, I would > agree. However > some of the changes are really modifications of existing interfaces. > >> >>> I agree on this. One thing I forgot to mention above is I think we >>> may have a few places in 3.x optimization where every way to do >>> something is deprecated. I suggest we take a careful look and >>> undeprecate where necessary to make 3.6 usable without warnings. I >>> may be wrong since I don't use that code myself; but I think its >>> worth taking a careful look and considering removal of some >>> deprecations. >> >> I'm against this. And is why I started the sure-to-be-controversial >> discussion on 4.0. > > I also don't really like the idea of undeprecating these things. > >> >> We agreed that things were (relatively) broken, and we agreed on a >> way forward (fluent API, refactoring of the "optim" classes); yet >> things don't move, because there is no urge to fix them since new >> features can be back-ported indefinitely to the 3.x series. > > No, things don't move because I didn't find time. I am really, > really busy doing lots of different stuff. I am also really, really > aware this API should be improved and fluent API is still a way I > would > like to explore for this. And no, I am not sure this will work and > 4.x will see the end of these problems. > >> >> Undeprecating what we agreed should be deprecated would only >> reinforce that feeling, and certainly won't attract attention that >> we need help to make progress. >> [And, in addition, 3.x is tied to old Java5 (known tune)...] >> >> In summary, I think that new features should only go to the master >> branch, while only bug-fixes would be back-ported to MATH_3_X. >> Thus everybody can have the best of both, while reducing the >> amount of work for the developers. Continuing in this way, and >> we'll soon have to also "forward-port" bugs reported against the >> 3.x series. :-/ > > Hey, I already do that! The following one-liner is my new > favorite: > > git diff -p MATH_3_X~1 MATH_3_X | sed 's,math3,math4,g' | patch -p1 > > Yes, it is cumbersome.
I am as busy and over-subscribed as anyone and agree it is a little cumbersome; but I am happy to do it so users can have something stable to work with. Realize that they too are very busy and much as we may like to ponder over the best way to keep refactoring our API, they just want to solve practical problems (why [math] was created in the first place) and once they have invested the time necessary to figure out how to get something done, they are not going to be thrilled about the prospect of having to invest more time learning how we have decided to change something. I know we have some API bugs that are so bad that they keep us from being able to deliver functionality. I know those need to be fixed. But I also know a library without a stable API is not suitable for widespread use and like it or not, we have become widely used. The research that I did in preparation for my apacachecon talk this year showed that we 3.x is very widely deployed. I think we should continue to support this series and I would like to do that, both in terms of bug fixes and new features. I also think we should change our deprecation strategy to only deprecate where there is a recommended alternative in the released code. I ask that we think about users actually using the library. Who likes to have deprecation warnings when they write new code using something? Who likes to struggle to get something working using a difficult-to-work-with API and then have to struggle again to figure out how to use a maybe-slightly-better API to get new features? Think about your own experience using other people's APIs. Please lets think about our users, people. Phil > > best regards, > Luc > >> >> >> Gilles >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
