commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math] Releasing 4.0? (Was: releasing 3.6 ?)
Date Fri, 06 Nov 2015 13:55:31 GMT
Hi Luc.

On Fri, 06 Nov 2015 10:04:23 +0100, 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.

There are two parts to that task: delete the deprecated code, and 
provide
the same (or better) functionality with new code.
I thought that the "delete" updates had been performed by Thomas.
Is there anything else that must go, but still is in master, and is not
deprecated in MATH_3_X?
If so, a JIRA "task" issue should indicate what to do, and this should 
be
resolved before release (IMHO).

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

Yes, but I mean that
1. we should list all agreed changes even if they are not implemented
    (like for "optim"),
2. then, the scene is set for 4.0 (and the release could indeed miss
    many bits, for which users will need 3.6),
2. we can add classes and methods in 4.x (x > 0), and where not
    possible (Java "interface"), then we'll go on and create 5.x.
[As someone said, plenty of integers left...]

"Release early, release often".
We still do neither.
Despite several developers agreeing on the principle, I'm being put in
the position to argue against "Release later"...

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

I've mixed feelings about MATH_3_X.  I now realize that I had 
unconsciously
imagined that it would be short-lived (so the few new features 
introduced
during that period could indeed be routinely back-ported).

Providing longer-term bug-fix support is a good thing.
Back-porting everything is IMO definitely a bad idea.

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

4.0 will be pristine (w.r.t our current view on the design): no ugly 
API
since all that suck should have been deleted!

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

Fine, if this is in the pipe...
But I'd insist that we clearly separate the issues of "complete" 
refactoring
from other modifications.
E.g. "optim" must be refactored, and that can be done in 4.x (x > 0)
because we (re)start from scratch.

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

I did not blame you, and certainly would not want to.
I see it as a "community" problem. Really.
We all decide on something but
  * there are areas in the code repository where it is extremely 
difficult
    to make disruptive changes (e.g. "stat", "exception")
  * there are areas where only one person performs very thorough changes
    (e.g. "geometry", "neuralnet")
  * there are areas left in disarray waiting for one volunteer to do all
    the work whereas the solution was promoted by a majority (e.g. 
"optim").

> And no, I am not sure this will work and
> 4.x will see the end of these problems.

We cannot be sure, nor should that fact prevent us from going forward
(i.e. "release  early").

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

Right, indeed.
I was stressing that it'll not be getting any better, unless we
stop feeding the MATH_3_X branch.

People who want _new_ features should go forward with us.  Users that
are content with existing features will remain happy even if the 3.x
series only contains bug-fixes.

The current state of matters did not bring any new contributors, only
more work for those already here.

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

It's as simple as it can be (thanks for the tip!) but, multiplied by 
the
number of commits, it's nevertheless becoming a severe burden.

To summarize, I'm not actually asking that the 3.6 and 4.0 releases be
synchronized!
I propose that
1. we start thinking of each as providing a different service 
(bug-fixes
    vs features) to the users of CM, and
2. that we work together on a roadmap that will set a target date for 
the
    4.0 release.


Best regards,
Gilles


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


Mime
View raw message