You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles <gi...@harfang.homelinux.org> on 2015/11/05 12:25:32 UTC
[Math] Releasing 4.0? (Was: releasing 3.6 ?)
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?
Regards,
Gilles
> What do other developers want to have in the 3.6 release?
>
> Of course, I volunteer to be the release manager.
>
> best regards,
> Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Releasing 4.0? (Was: releasing 3.6 ?)
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Le 06/11/2015 14:55, Gilles a écrit :
> 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.
Not only that.
When an interface intended to be implemented by users is changed
(say FirstOrderDifferentialEquations for example, then as soon as a
user update to the version after the change, all its implementations
have to be changed at once.
> 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?
Yes, at least in ode (interface changes) and geometry (semantic changes).
> If so, a JIRA "task" issue should indicate what to do, and this should be
> resolved before release (IMHO).
OK for a JIRA task, but we cannot deprecate the user interfaces involved.
>
>>> 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...]
With Phil proposal to use an even/odd scheme, things become simpler.
>
> "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!
Yes, but as explained above, we need to provide also support for the
new user interfaces. Typically if FirstOrderDifferentialEquations as
well as two or three other user interfaces change in ode, all our
ode code should support all these changes as soon as 4.0.
>
>>> 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.
With even/odd scheme, yes.
>
>>>> 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").
Agreed.
>
>>> 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.
I do need some new features for libraries that do use Apache Commons
Math. However, since I need them now, I implement them in both 3.X
which can be available in a short time frame and in 4.0 for later.
I cannot wait for 4.0 for some of these features.
>
> The current state of matters did not bring any new contributors, only
> more work for those already here.
Hey, we have Otmar here now.
>
>> 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.
Let's see if we can go for the even/odd scheme.
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
Re: [Math] Releasing 4.0? (Was: releasing 3.6 ?)
Posted by Gilles <gi...@harfang.homelinux.org>.
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
Re: [Math] Releasing 4.0? (Was: releasing 3.6 ?)
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 6 Nov 2015 07:02:58 -0700, Phil Steitz wrote:
> 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.
Do you offer to do it for all the commits *I* might push to the
"master" branch?
That would be nice; thank you!
But is only part of the request: that new features exist in 3.x
should not frustrate those of use who would like to rely on an
official release of compatibility-breaking features.
> 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.
It would be nice to consider what I wrote rather than summarily
imply that, should my viewpoint come to pass, we'd be forcing
anyone to learn new ways to do the same things.
A. People are happy with 3.5; they don't need to touch anything
(i.e. they keep using 3.5).
B. People fear that they might be hit by a bug: they switch to 3.6.
C. People want to use new features: "math4" must be an *additional*
dependency. For refactored functionalities, people are _free_
to update their codes, or not. Whatever they choose, their
code will depend on the "current" state of CM.
IIUC, your scenario is
D. People ask that we do more work so that they can benefit from
new features without adding one line in their dependency file.
I consider this an unreasonable expectation.
Then the following may indeed seem problematic:
E. People are hit by a bug which we deem to complicated to fix
without breaking compatibility.
But in fact, it's their call: either they help us by providing
a patch that we can include in 3.x, or they have to accept to
share the effort (we fix in 4.0, they upgrade to it).
> 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.
So, in short, you've just stated that
1. API must be changed,
2. API must not be changed.
That general problem of CM exists because it is inherent to an
open-ended development (in terms of features) with no specific
targets other than "[someone needs this code now] to solve a
practical problem".
It's neither good nor bad. In this situation, my position is
that we should be ready, even willing, to make disruptive changes
in new releases. Knowing that it won't hurt anyone but the most
lazy fellows.
On the other hand, it is perfectly reasonable to decide that
CM must become a legacy project, bent on accepting utterly
contorted ways to fix bugs without ever touching on its API
again.
Personally, I clearly don't want this (both as a user and
as a developer).
> The research that I did in preparation for my
> apacachecon talk this year showed that we 3.x is very widely
> deployed.
Would be interesting to know the above "A", "B", "C", "D", "E"
user types repartition.
> I think we should continue to support this series and I
> would like to do that, both in terms of bug fixes
Good IMO (as said in previous post).
> and new features.
Bad IMO (ditto). And unnecessary burden.
Bad for CM. Bad for developers, bad for users, bad for attracting
contributors.
> I also think we should change our deprecation strategy to only
> deprecate where there is a recommended alternative in the released
> code.
It's not because you *hide* what needs improving that the problem
disappears.
IMHO, it is good that users see that we think about our code,
that we have identified problems. And that we lack the resources
to fix all of them.
[Perhaps deprecation warnings will get us more visibility than
the "caveat" warnings in the release notes!]
> I ask that we think about users actually using the library.
I ask that we have consideration for the whole food-chain.
> Who likes to have deprecation warnings when they write new code
> using something?
Those who cannot bear it will find how to redirect the messages to
/dev/null. ;-)
> 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?
Not many people I guess.
As I suggest above, shall we define what kind of project CM is
("legacy" or not) and agree on what it means in terms of true
expectations, for users and developers?
I'm responsible of the half-baked versions of the successively
and iteratively revised APIs of "optim".
The history is somewhere in the ML archive.
> Think about your own experience using other people's
> APIs.
I think that we are overly cautious about compatibility with
outdated code, tools and practice.
I am also quite convinced that nobody can come up with a
case that we performed gratuitous changes (assuming that
CM is not "legacy").
> Please lets think about our users, people.
If people want to complain, they are welcome in this forum
where we help them help us (!) find a way to solve their
"practical problems".
If you are happy about how the CM community has not grown
to match the growth of the codebase, then we agree to
disagree on what CM should be, and the community will
probably shrink as a consequence of not taking *all* of
us into account.
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Releasing 4.0? (Was: releasing 3.6 ?)
Posted by Phil Steitz <ph...@gmail.com>.
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-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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Releasing 4.0? (Was: releasing 3.6 ?)
Posted by luc <lu...@spaceroots.org>.
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.
best regards,
Luc
>
>
> 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
Re: [Math] Releasing 4.0? (Was: releasing 3.6 ?)
Posted by Gilles <gi...@harfang.homelinux.org>.
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?
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...
Let's not forget that we agreed to work towards 4.0, and that the 3.x
branch was an afterthought.
Since we now effectively maintain two versions of CM, it makes sense
to allow people to benefit from the extra work.
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.
> 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.
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.
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. :-/
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Releasing 4.0? (Was: releasing 3.6 ?)
Posted by Phil Steitz <ph...@gmail.com>.
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.
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.
Phil
>
> best regards,
> Luc
>
>> Regards,
>> Gilles
>>
>>> What do other developers want to have in the 3.6 release?
>>>
>>> Of course, I volunteer to be the release manager.
>>>
>>> best regards,
>>> Luc
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Releasing 4.0? (Was: releasing 3.6 ?)
Posted by Luc Maisonobe <lu...@spaceroots.org>.
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.
best regards,
Luc
>
> Regards,
> Gilles
>
>> What do other developers want to have in the 3.6 release?
>>
>> Of course, I volunteer to be the release manager.
>>
>> best regards,
>> Luc
>
>
>
> ---------------------------------------------------------------------
> 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