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