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/01/06 23:10:33 UTC
[Math] Next release: 4.0 or 3.5 ?
Hi.
Do we head towards 4.0, starting to implement the dreaded
breakings? ;-)
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Next release: 4.0 or 3.5 ?
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Am Thu, 08 Jan 2015 16:42:14 +0100
schrieb Gilles <gi...@harfang.homelinux.org>:
> On Thu, 8 Jan 2015 10:24:49 -0500, Gary Gregory wrote:
> > On Thu, Jan 8, 2015 at 9:24 AM, Luc Maisonobe <lu...@spaceroots.org>
> > wrote:
> >
> >> Le 08/01/2015 07:59, Thomas Neidhart a écrit :
> >> > On 01/08/2015 02:40 AM, Phil Steitz wrote:
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>> On Jan 6, 2015, at 3:10 PM, Gilles
> >> <gi...@harfang.homelinux.org>
> >> wrote:
> >> >>>
> >> >>> Hi.
> >> >>>
> >> >>> Do we head towards 4.0, starting to implement the dreaded
> >> >>> breakings? ;-)
> >> >>
> >> >> How about starting a new 4.0 branch and keeping head set up for
> >> 3.x so
> >> we can cut 3.4.1 when the bugs start coming in against 3.4.
> >> >
> >> > +1
> >>
> >> Of course a branch is needed, but why consider master should be
> >> 3.x and
> >> 4.0 should be a side branch.
> >>
> >> If we consider 4.0 is the future and 3.x is only for bug fixes,
> >> then 4.0
> >> should be master and 3.x a side branch. This side branch could be
> >> created later on, if needed. It is straightforward to create new
> >> branches in git even from very old commits, so the branch creation
> >> can
> >> be delayed until needed (and only if needed).
>
> What would happen if we then need to merge (backport) a modification
> performed under the "o.a.c.math4" hierarchy into the "o.a.c.math3"
> hierarchy of that branch?
> Would two files "o/a/c/math4/SomeAlgo.java" and
> "o/a/c/math3/SomeAlgo.java"
> be considered the same w.r.t. to "diff"? Or would we need to
> manually copy
> from "math4"?
Git does detect rename-and-modify, however it is an heuristic so you
cannot rely on it. But at least interactively you can diff aribritary
file/revisions.
(internally of course Git does not store diffs anyway, so it is just a
representation of a commit - which is also used in some situations for
merging).
Gruss
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Next release: 4.0 or 3.5 ?
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Le 08/01/2015 16:42, Gilles a écrit :
> On Thu, 8 Jan 2015 10:24:49 -0500, Gary Gregory wrote:
>> On Thu, Jan 8, 2015 at 9:24 AM, Luc Maisonobe <lu...@spaceroots.org> wrote:
>>
>>> Le 08/01/2015 07:59, Thomas Neidhart a écrit :
>>> > On 01/08/2015 02:40 AM, Phil Steitz wrote:
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>> On Jan 6, 2015, at 3:10 PM, Gilles <gi...@harfang.homelinux.org>
>>> wrote:
>>> >>>
>>> >>> Hi.
>>> >>>
>>> >>> Do we head towards 4.0, starting to implement the dreaded
>>> >>> breakings? ;-)
>>> >>
>>> >> How about starting a new 4.0 branch and keeping head set up for
>>> 3.x so
>>> we can cut 3.4.1 when the bugs start coming in against 3.4.
>>> >
>>> > +1
>>>
>>> Of course a branch is needed, but why consider master should be 3.x and
>>> 4.0 should be a side branch.
>>>
>>> If we consider 4.0 is the future and 3.x is only for bug fixes, then 4.0
>>> should be master and 3.x a side branch. This side branch could be
>>> created later on, if needed. It is straightforward to create new
>>> branches in git even from very old commits, so the branch creation can
>>> be delayed until needed (and only if needed).
>
> What would happen if we then need to merge (backport) a modification
> performed under the "o.a.c.math4" hierarchy into the "o.a.c.math3"
> hierarchy of that branch?
> Would two files "o/a/c/math4/SomeAlgo.java" and "o/a/c/math3/SomeAlgo.java"
> be considered the same w.r.t. to "diff"? Or would we need to manually copy
> from "math4"?
Git knows about renaming files, so an attempt to do a direct merge
(or a git cherry-pick) would lead to a conflict being detected (file
moved in one branch and file change in another branch). I just did a
small test for it.
So we would need to do a "git diff -p" to create a patch, use a "sed"
command or equivalent to replace the package name, and "git apply" to
apply it. In any case, this would be the exact same situation if 4.0
were a side branch and 3.x master.
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] Next release: 4.0 or 3.5 ?
Posted by Gilles <gi...@harfang.homelinux.org>.
On Thu, 8 Jan 2015 10:24:49 -0500, Gary Gregory wrote:
> On Thu, Jan 8, 2015 at 9:24 AM, Luc Maisonobe <lu...@spaceroots.org>
> wrote:
>
>> Le 08/01/2015 07:59, Thomas Neidhart a écrit :
>> > On 01/08/2015 02:40 AM, Phil Steitz wrote:
>> >>
>> >>
>> >>
>> >>
>> >>> On Jan 6, 2015, at 3:10 PM, Gilles
>> <gi...@harfang.homelinux.org>
>> wrote:
>> >>>
>> >>> Hi.
>> >>>
>> >>> Do we head towards 4.0, starting to implement the dreaded
>> >>> breakings? ;-)
>> >>
>> >> How about starting a new 4.0 branch and keeping head set up for
>> 3.x so
>> we can cut 3.4.1 when the bugs start coming in against 3.4.
>> >
>> > +1
>>
>> Of course a branch is needed, but why consider master should be 3.x
>> and
>> 4.0 should be a side branch.
>>
>> If we consider 4.0 is the future and 3.x is only for bug fixes, then
>> 4.0
>> should be master and 3.x a side branch. This side branch could be
>> created later on, if needed. It is straightforward to create new
>> branches in git even from very old commits, so the branch creation
>> can
>> be delayed until needed (and only if needed).
What would happen if we then need to merge (backport) a modification
performed under the "o.a.c.math4" hierarchy into the "o.a.c.math3"
hierarchy of that branch?
Would two files "o/a/c/math4/SomeAlgo.java" and
"o/a/c/math3/SomeAlgo.java"
be considered the same w.r.t. to "diff"? Or would we need to manually
copy
from "math4"?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Next release: 4.0 or 3.5 ?
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Jan 8, 2015 at 9:24 AM, Luc Maisonobe <lu...@spaceroots.org> wrote:
> Le 08/01/2015 07:59, Thomas Neidhart a écrit :
> > On 01/08/2015 02:40 AM, Phil Steitz wrote:
> >>
> >>
> >>
> >>
> >>> On Jan 6, 2015, at 3:10 PM, Gilles <gi...@harfang.homelinux.org>
> wrote:
> >>>
> >>> Hi.
> >>>
> >>> Do we head towards 4.0, starting to implement the dreaded
> >>> breakings? ;-)
> >>
> >> How about starting a new 4.0 branch and keeping head set up for 3.x so
> we can cut 3.4.1 when the bugs start coming in against 3.4.
> >
> > +1
>
> Of course a branch is needed, but why consider master should be 3.x and
> 4.0 should be a side branch.
>
> If we consider 4.0 is the future and 3.x is only for bug fixes, then 4.0
> should be master and 3.x a side branch. This side branch could be
> created later on, if needed. It is straightforward to create new
> branches in git even from very old commits, so the branch creation can
> be delayed until needed (and only if needed).
>
+1
Gary
>
> best regards,
> Luc
>
>
> >
> > Thomas
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [Math] Next release: 4.0 or 3.5 ?
Posted by Thomas Neidhart <th...@gmail.com>.
On 01/08/2015 05:25 PM, Luc Maisonobe wrote:
> Le 08/01/2015 17:02, Phil Steitz a écrit :
>> On 1/8/15 7:24 AM, Luc Maisonobe wrote:
>>> Le 08/01/2015 07:59, Thomas Neidhart a écrit :
>>>> On 01/08/2015 02:40 AM, Phil Steitz wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Jan 6, 2015, at 3:10 PM, Gilles <gi...@harfang.homelinux.org> wrote:
>>>>>>
>>>>>> Hi.
>>>>>>
>>>>>> Do we head towards 4.0, starting to implement the dreaded
>>>>>> breakings? ;-)
>>>>> How about starting a new 4.0 branch and keeping head set up for 3.x so we can cut 3.4.1 when the bugs start coming in against 3.4.
>>>> +1
>>> Of course a branch is needed, but why consider master should be 3.x and
>>> 4.0 should be a side branch.
>>
>> I am OK either way. We just need to be able to easily cut 3.4.1.
>> Due to my mistake, we need to do that ASAP, so whatever git games
>> need to be played to get it set up so we can release from it, we
>> need to do it.
>
> Don't worry.
>
> I'm on it. I created the version and issue in Jira, and am currently
> creating the release-candidates branch.
>
> Stay tuned for a new vote in the upcoming hours ...
I am fine with either approach, but just wanted to point out we should
not stop supporting the 3.x branch, and I am also willing to invest time
and energy into this.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Next release: 4.0 or 3.5 ?
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Le 08/01/2015 17:02, Phil Steitz a écrit :
> On 1/8/15 7:24 AM, Luc Maisonobe wrote:
>> Le 08/01/2015 07:59, Thomas Neidhart a écrit :
>>> On 01/08/2015 02:40 AM, Phil Steitz wrote:
>>>>
>>>>
>>>>
>>>>> On Jan 6, 2015, at 3:10 PM, Gilles <gi...@harfang.homelinux.org> wrote:
>>>>>
>>>>> Hi.
>>>>>
>>>>> Do we head towards 4.0, starting to implement the dreaded
>>>>> breakings? ;-)
>>>> How about starting a new 4.0 branch and keeping head set up for 3.x so we can cut 3.4.1 when the bugs start coming in against 3.4.
>>> +1
>> Of course a branch is needed, but why consider master should be 3.x and
>> 4.0 should be a side branch.
>
> I am OK either way. We just need to be able to easily cut 3.4.1.
> Due to my mistake, we need to do that ASAP, so whatever git games
> need to be played to get it set up so we can release from it, we
> need to do it.
Don't worry.
I'm on it. I created the version and issue in Jira, and am currently
creating the release-candidates branch.
Stay tuned for a new vote in the upcoming hours ...
best regards,
Luc
>
> Phil
>>
>> If we consider 4.0 is the future and 3.x is only for bug fixes, then 4.0
>> should be master and 3.x a side branch. This side branch could be
>> created later on, if needed. It is straightforward to create new
>> branches in git even from very old commits, so the branch creation can
>> be delayed until needed (and only if needed).
>>
>> best regards,
>> Luc
>>
>>
>>> Thomas
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Next release: 4.0 or 3.5 ?
Posted by Phil Steitz <ph...@gmail.com>.
On 1/8/15 7:24 AM, Luc Maisonobe wrote:
> Le 08/01/2015 07:59, Thomas Neidhart a écrit :
>> On 01/08/2015 02:40 AM, Phil Steitz wrote:
>>>
>>>
>>>
>>>> On Jan 6, 2015, at 3:10 PM, Gilles <gi...@harfang.homelinux.org> wrote:
>>>>
>>>> Hi.
>>>>
>>>> Do we head towards 4.0, starting to implement the dreaded
>>>> breakings? ;-)
>>> How about starting a new 4.0 branch and keeping head set up for 3.x so we can cut 3.4.1 when the bugs start coming in against 3.4.
>> +1
> Of course a branch is needed, but why consider master should be 3.x and
> 4.0 should be a side branch.
I am OK either way. We just need to be able to easily cut 3.4.1.
Due to my mistake, we need to do that ASAP, so whatever git games
need to be played to get it set up so we can release from it, we
need to do it.
Phil
>
> If we consider 4.0 is the future and 3.x is only for bug fixes, then 4.0
> should be master and 3.x a side branch. This side branch could be
> created later on, if needed. It is straightforward to create new
> branches in git even from very old commits, so the branch creation can
> be delayed until needed (and only if needed).
>
> best regards,
> Luc
>
>
>> Thomas
>>
>> ---------------------------------------------------------------------
>> 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] Next release: 4.0 or 3.5 ?
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Le 08/01/2015 07:59, Thomas Neidhart a écrit :
> On 01/08/2015 02:40 AM, Phil Steitz wrote:
>>
>>
>>
>>
>>> On Jan 6, 2015, at 3:10 PM, Gilles <gi...@harfang.homelinux.org> wrote:
>>>
>>> Hi.
>>>
>>> Do we head towards 4.0, starting to implement the dreaded
>>> breakings? ;-)
>>
>> How about starting a new 4.0 branch and keeping head set up for 3.x so we can cut 3.4.1 when the bugs start coming in against 3.4.
>
> +1
Of course a branch is needed, but why consider master should be 3.x and
4.0 should be a side branch.
If we consider 4.0 is the future and 3.x is only for bug fixes, then 4.0
should be master and 3.x a side branch. This side branch could be
created later on, if needed. It is straightforward to create new
branches in git even from very old commits, so the branch creation can
be delayed until needed (and only if needed).
best regards,
Luc
>
> Thomas
>
> ---------------------------------------------------------------------
> 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] Next release: 4.0 or 3.5 ?
Posted by Thomas Neidhart <th...@gmail.com>.
On 01/08/2015 02:40 AM, Phil Steitz wrote:
>
>
>
>
>> On Jan 6, 2015, at 3:10 PM, Gilles <gi...@harfang.homelinux.org> wrote:
>>
>> Hi.
>>
>> Do we head towards 4.0, starting to implement the dreaded
>> breakings? ;-)
>
> How about starting a new 4.0 branch and keeping head set up for 3.x so we can cut 3.4.1 when the bugs start coming in against 3.4.
+1
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Next release: 4.0 or 3.5 ?
Posted by Gilles <gi...@harfang.homelinux.org>.
On Wed, 7 Jan 2015 18:40:08 -0700, Phil Steitz wrote:
>> On Jan 6, 2015, at 3:10 PM, Gilles <gi...@harfang.homelinux.org>
>> wrote:
>>
>> Hi.
>>
>> Do we head towards 4.0, starting to implement the dreaded
>> breakings? ;-)
>
> How about starting a new 4.0 branch and keeping head set up for 3.x
> so we can cut 3.4.1 when the bugs start coming in against 3.4.
It looks like an interesting experiment.
So by switching branch, we should be able to create either the
compatible or the incompatible JAR?
Shall we start with an empty branch, and gradually add the "new"
packages (with the top-level name set to "math4")?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Next release: 4.0 or 3.5 ?
Posted by Phil Steitz <ph...@gmail.com>.
> On Jan 6, 2015, at 3:10 PM, Gilles <gi...@harfang.homelinux.org> wrote:
>
> Hi.
>
> Do we head towards 4.0, starting to implement the dreaded
> breakings? ;-)
How about starting a new 4.0 branch and keeping head set up for 3.x so we can cut 3.4.1 when the bugs start coming in against 3.4.
Phil
>
>
> 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] Next release: 4.0 or 3.5 ?
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Hi all,
It seems several mials piled up before I can answer, so I'll try to
catch up in one post.
Le 08/01/2015 14:55, Gilles a écrit :
> On Thu, 8 Jan 2015 07:53:06 -0500, Gary Gregory wrote:
>> On Thu, Jan 8, 2015 at 6:17 AM, Gilles <gi...@harfang.homelinux.org>
>> wrote:
>>
>>> On Thu, 8 Jan 2015 01:25:42 +0000, sebb wrote:
>>>
>>>> On 8 January 2015 at 00:43, Gilles <gi...@harfang.homelinux.org>
>>>> wrote:
>>>>
>>>>> On Wed, 7 Jan 2015 14:46:19 +0000, sebb wrote:
>>>>>
>>>>>>
>>>>>> On 7 January 2015 at 08:23, luc <lu...@spaceroots.org> wrote:
>>>>>>
>>>>>>>
>>>>>>> Le 2015-01-06 23:13, Gilles a écrit :
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, 06 Jan 2015 23:10:33 +0100, Gilles wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi.
>>>>>>>>>
>>>>>>>>> Do we head towards 4.0, starting to implement the dreaded
>>>>>>>>> breakings? ;-)
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> +1, +1, +1, +1 !!!
>>>>>>>
>>>>>>> To be serious, yes, we are really stuck by now and several pending
>>>>>>> changes should be done. We talked about fluent API for optimizers
>>>>>>> and it was too much too squeeze without breaking API. I attempted
>>>>>>> the same for ODE, and here again it was postponed as it touched
>>>>>>> user level interfaces.
>>>>>>>
>>>>>>> I would even say that we should from the beginning change the top
>>>>>>> level package name to 4.0 so users can test earlier the changes as
>>>>>>> we prepare the next version, using only one feature at a time and
>>>>>>> preserving the older release for the other features.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> That needs to be done carefully to avoid creating jar hell.
>>>>>> What exactly are you proposing here?
I was proposing to change both the top level package to a.o.c.math4 and
to change the maven coordinates, so both artifacts can be used in
parallel for users who want to switch smoothly. They could use some
stuff from math3 and other stuff from math4. All stuff from math4 would
only depends on math4, i.e. both jars are independent.
>>>>>>
>>>>>> Are you referring to SNAPSHOTs only (in which case caution is only
>>>>>> advisable)?
>>>>>>
>>>>>> If you are proposing to release jars with the new package name, then
>>>>>> this needs to be done in a separate jar with new Maven coords.
Yes.
>>>>>>
>>>>>> It would be possible to gradually add more packages to the new jar as
>>>>>> the original ones are converted.
>>>>>>
>>>>>
>>>>>
>>>>> IIUC, we'd change the top-level package in "trunk".
>>>>> [Not releasing anything. Beta-testers would need to check out (i.e.
>>>>> "clone") the source repository and compile the library by themselves.]
>>>>>
>>>>>
>>>> If you only used the new package on the updated API it would be more
>>>> obvious what was the proposed new API and what was old.
Please no. This would be a nightmare to maintain. We do have some
low level stuff used by our public API. What if we need to change
a low level for the need of math4 (say add a new exception). We would
end up with duplicating again and again. We already have some features
that are in *3 different implementations* in math3. My goal here is
more to remove old stuff than to pile up again.
>>>>
>>>>
>>> Pushing this further, couldn't we provide two top-level packages already
>>> in a backward-compatible release? I.e. in, say, CM 3.5, there would be
>>> o.a.c.math3 -> all the existing code + bug fixes
>>> o.a.c.math4 -> redesigned bits + new features
No. There are low level stuff that would need to be duplicated in
both hierarchy, duplicating again (think exceptions, think all the
utilities). We are *not* able anymore to maintain 4.0/3.x compatibility
and you would like us to expand it further within the library.
I would veto such a change.
>>
>>
>> This sounds like a recipe for jar hell. We have to think about a large
>> app
>> with dependencies on both math3 and 4, meaning both jars are on the CP
>> and
>> in use.
>
> Why would someone keep both JARs in the CP, if one contains everything?
> A problem I could see is that classes from math3 could be picked from the
> old JAR whereas some bug would have been fixed in the new JAR only.
> The contents of both JARs would be compatible (the same actually), so there
> is no hell.
Jar hell is when you get cross dependencies. By completely cutting the
link between 3.x and 4.0, I precisely want to avoid jar hell.
If a new feature (or a redesigned feature) is in 4.0, then users who
want to use it would have to get a dependency on math4. These people
could have at the same time another unrelated dependency to math3 for
other features. Math4 would not know anything about math3.
The user would then be able to update the top level application
smoothly, starting with one or two packages, replacing some math3 by
some math4, until there are no math3 dependencies anymore.
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] Next release: 4.0 or 3.5 ?
Posted by Gilles <gi...@harfang.homelinux.org>.
On Thu, 8 Jan 2015 07:53:06 -0500, Gary Gregory wrote:
> On Thu, Jan 8, 2015 at 6:17 AM, Gilles <gi...@harfang.homelinux.org>
> wrote:
>
>> On Thu, 8 Jan 2015 01:25:42 +0000, sebb wrote:
>>
>>> On 8 January 2015 at 00:43, Gilles <gi...@harfang.homelinux.org>
>>> wrote:
>>>
>>>> On Wed, 7 Jan 2015 14:46:19 +0000, sebb wrote:
>>>>
>>>>>
>>>>> On 7 January 2015 at 08:23, luc <lu...@spaceroots.org> wrote:
>>>>>
>>>>>>
>>>>>> Le 2015-01-06 23:13, Gilles a écrit :
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, 06 Jan 2015 23:10:33 +0100, Gilles wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi.
>>>>>>>>
>>>>>>>> Do we head towards 4.0, starting to implement the dreaded
>>>>>>>> breakings? ;-)
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> +1, +1, +1, +1 !!!
>>>>>>
>>>>>> To be serious, yes, we are really stuck by now and several
>>>>>> pending
>>>>>> changes should be done. We talked about fluent API for
>>>>>> optimizers
>>>>>> and it was too much too squeeze without breaking API. I
>>>>>> attempted
>>>>>> the same for ODE, and here again it was postponed as it touched
>>>>>> user level interfaces.
>>>>>>
>>>>>> I would even say that we should from the beginning change the
>>>>>> top
>>>>>> level package name to 4.0 so users can test earlier the changes
>>>>>> as
>>>>>> we prepare the next version, using only one feature at a time
>>>>>> and
>>>>>> preserving the older release for the other features.
>>>>>>
>>>>>
>>>>>
>>>>> That needs to be done carefully to avoid creating jar hell.
>>>>> What exactly are you proposing here?
>>>>>
>>>>> Are you referring to SNAPSHOTs only (in which case caution is
>>>>> only
>>>>> advisable)?
>>>>>
>>>>> If you are proposing to release jars with the new package name,
>>>>> then
>>>>> this needs to be done in a separate jar with new Maven coords.
>>>>>
>>>>> It would be possible to gradually add more packages to the new
>>>>> jar as
>>>>> the original ones are converted.
>>>>>
>>>>
>>>>
>>>> IIUC, we'd change the top-level package in "trunk".
>>>> [Not releasing anything. Beta-testers would need to check out
>>>> (i.e.
>>>> "clone") the source repository and compile the library by
>>>> themselves.]
>>>>
>>>>
>>> If you only used the new package on the updated API it would be
>>> more
>>> obvious what was the proposed new API and what was old.
>>>
>>>
>> Pushing this further, couldn't we provide two top-level packages
>> already
>> in a backward-compatible release? I.e. in, say, CM 3.5, there would
>> be
>> o.a.c.math3 -> all the existing code + bug fixes
>> o.a.c.math4 -> redesigned bits + new features
>
>
> This sounds like a recipe for jar hell. We have to think about a
> large app
> with dependencies on both math3 and 4, meaning both jars are on the
> CP and
> in use.
Why would someone keep both JARs in the CP, if one contains everything?
A problem I could see is that classes from math3 could be picked from
the
old JAR whereas some bug would have been fixed in the new JAR only.
The contents of both JARs would be compatible (the same actually), so
there
is no hell.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Next release: 4.0 or 3.5 ?
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Jan 8, 2015 at 6:17 AM, Gilles <gi...@harfang.homelinux.org> wrote:
> On Thu, 8 Jan 2015 01:25:42 +0000, sebb wrote:
>
>> On 8 January 2015 at 00:43, Gilles <gi...@harfang.homelinux.org> wrote:
>>
>>> On Wed, 7 Jan 2015 14:46:19 +0000, sebb wrote:
>>>
>>>>
>>>> On 7 January 2015 at 08:23, luc <lu...@spaceroots.org> wrote:
>>>>
>>>>>
>>>>> Le 2015-01-06 23:13, Gilles a écrit :
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, 06 Jan 2015 23:10:33 +0100, Gilles wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi.
>>>>>>>
>>>>>>> Do we head towards 4.0, starting to implement the dreaded
>>>>>>> breakings? ;-)
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> +1, +1, +1, +1 !!!
>>>>>
>>>>> To be serious, yes, we are really stuck by now and several pending
>>>>> changes should be done. We talked about fluent API for optimizers
>>>>> and it was too much too squeeze without breaking API. I attempted
>>>>> the same for ODE, and here again it was postponed as it touched
>>>>> user level interfaces.
>>>>>
>>>>> I would even say that we should from the beginning change the top
>>>>> level package name to 4.0 so users can test earlier the changes as
>>>>> we prepare the next version, using only one feature at a time and
>>>>> preserving the older release for the other features.
>>>>>
>>>>
>>>>
>>>> That needs to be done carefully to avoid creating jar hell.
>>>> What exactly are you proposing here?
>>>>
>>>> Are you referring to SNAPSHOTs only (in which case caution is only
>>>> advisable)?
>>>>
>>>> If you are proposing to release jars with the new package name, then
>>>> this needs to be done in a separate jar with new Maven coords.
>>>>
>>>> It would be possible to gradually add more packages to the new jar as
>>>> the original ones are converted.
>>>>
>>>
>>>
>>> IIUC, we'd change the top-level package in "trunk".
>>> [Not releasing anything. Beta-testers would need to check out (i.e.
>>> "clone") the source repository and compile the library by themselves.]
>>>
>>>
>> If you only used the new package on the updated API it would be more
>> obvious what was the proposed new API and what was old.
>>
>>
> Pushing this further, couldn't we provide two top-level packages already
> in a backward-compatible release? I.e. in, say, CM 3.5, there would be
> o.a.c.math3 -> all the existing code + bug fixes
> o.a.c.math4 -> redesigned bits + new features
This sounds like a recipe for jar hell. We have to think about a large app
with dependencies on both math3 and 4, meaning both jars are on the CP and
in use.
Gary
>
>
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [Math] Next release: 4.0 or 3.5 ?
Posted by Gilles <gi...@harfang.homelinux.org>.
On Thu, 8 Jan 2015 01:25:42 +0000, sebb wrote:
> On 8 January 2015 at 00:43, Gilles <gi...@harfang.homelinux.org>
> wrote:
>> On Wed, 7 Jan 2015 14:46:19 +0000, sebb wrote:
>>>
>>> On 7 January 2015 at 08:23, luc <lu...@spaceroots.org> wrote:
>>>>
>>>> Le 2015-01-06 23:13, Gilles a écrit :
>>>>>
>>>>>
>>>>> On Tue, 06 Jan 2015 23:10:33 +0100, Gilles wrote:
>>>>>>
>>>>>>
>>>>>> Hi.
>>>>>>
>>>>>> Do we head towards 4.0, starting to implement the dreaded
>>>>>> breakings? ;-)
>>>>
>>>>
>>>>
>>>>
>>>> +1, +1, +1, +1 !!!
>>>>
>>>> To be serious, yes, we are really stuck by now and several pending
>>>> changes should be done. We talked about fluent API for optimizers
>>>> and it was too much too squeeze without breaking API. I attempted
>>>> the same for ODE, and here again it was postponed as it touched
>>>> user level interfaces.
>>>>
>>>> I would even say that we should from the beginning change the top
>>>> level package name to 4.0 so users can test earlier the changes as
>>>> we prepare the next version, using only one feature at a time and
>>>> preserving the older release for the other features.
>>>
>>>
>>> That needs to be done carefully to avoid creating jar hell.
>>> What exactly are you proposing here?
>>>
>>> Are you referring to SNAPSHOTs only (in which case caution is only
>>> advisable)?
>>>
>>> If you are proposing to release jars with the new package name,
>>> then
>>> this needs to be done in a separate jar with new Maven coords.
>>>
>>> It would be possible to gradually add more packages to the new jar
>>> as
>>> the original ones are converted.
>>
>>
>> IIUC, we'd change the top-level package in "trunk".
>> [Not releasing anything. Beta-testers would need to check out (i.e.
>> "clone") the source repository and compile the library by
>> themselves.]
>>
>
> If you only used the new package on the updated API it would be more
> obvious what was the proposed new API and what was old.
>
Pushing this further, couldn't we provide two top-level packages
already
in a backward-compatible release? I.e. in, say, CM 3.5, there would be
o.a.c.math3 -> all the existing code + bug fixes
o.a.c.math4 -> redesigned bits + new features
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Next release: 4.0 or 3.5 ?
Posted by sebb <se...@gmail.com>.
On 8 January 2015 at 00:43, Gilles <gi...@harfang.homelinux.org> wrote:
> On Wed, 7 Jan 2015 14:46:19 +0000, sebb wrote:
>>
>> On 7 January 2015 at 08:23, luc <lu...@spaceroots.org> wrote:
>>>
>>> Le 2015-01-06 23:13, Gilles a écrit :
>>>>
>>>>
>>>> On Tue, 06 Jan 2015 23:10:33 +0100, Gilles wrote:
>>>>>
>>>>>
>>>>> Hi.
>>>>>
>>>>> Do we head towards 4.0, starting to implement the dreaded
>>>>> breakings? ;-)
>>>
>>>
>>>
>>>
>>> +1, +1, +1, +1 !!!
>>>
>>> To be serious, yes, we are really stuck by now and several pending
>>> changes should be done. We talked about fluent API for optimizers
>>> and it was too much too squeeze without breaking API. I attempted
>>> the same for ODE, and here again it was postponed as it touched
>>> user level interfaces.
>>>
>>> I would even say that we should from the beginning change the top
>>> level package name to 4.0 so users can test earlier the changes as
>>> we prepare the next version, using only one feature at a time and
>>> preserving the older release for the other features.
>>
>>
>> That needs to be done carefully to avoid creating jar hell.
>> What exactly are you proposing here?
>>
>> Are you referring to SNAPSHOTs only (in which case caution is only
>> advisable)?
>>
>> If you are proposing to release jars with the new package name, then
>> this needs to be done in a separate jar with new Maven coords.
>>
>> It would be possible to gradually add more packages to the new jar as
>> the original ones are converted.
>
>
> IIUC, we'd change the top-level package in "trunk".
> [Not releasing anything. Beta-testers would need to check out (i.e.
> "clone") the source repository and compile the library by themselves.]
>
If you only used the new package on the updated API it would be more
obvious what was the proposed new API and what was old.
>
> 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] Next release: 4.0 or 3.5 ?
Posted by Gilles <gi...@harfang.homelinux.org>.
On Wed, 7 Jan 2015 14:46:19 +0000, sebb wrote:
> On 7 January 2015 at 08:23, luc <lu...@spaceroots.org> wrote:
>> Le 2015-01-06 23:13, Gilles a écrit :
>>>
>>> On Tue, 06 Jan 2015 23:10:33 +0100, Gilles wrote:
>>>>
>>>> Hi.
>>>>
>>>> Do we head towards 4.0, starting to implement the dreaded
>>>> breakings? ;-)
>>
>>
>>
>> +1, +1, +1, +1 !!!
>>
>> To be serious, yes, we are really stuck by now and several pending
>> changes should be done. We talked about fluent API for optimizers
>> and it was too much too squeeze without breaking API. I attempted
>> the same for ODE, and here again it was postponed as it touched
>> user level interfaces.
>>
>> I would even say that we should from the beginning change the top
>> level package name to 4.0 so users can test earlier the changes as
>> we prepare the next version, using only one feature at a time and
>> preserving the older release for the other features.
>
> That needs to be done carefully to avoid creating jar hell.
> What exactly are you proposing here?
>
> Are you referring to SNAPSHOTs only (in which case caution is only
> advisable)?
>
> If you are proposing to release jars with the new package name, then
> this needs to be done in a separate jar with new Maven coords.
>
> It would be possible to gradually add more packages to the new jar as
> the original ones are converted.
IIUC, we'd change the top-level package in "trunk".
[Not releasing anything. Beta-testers would need to check out (i.e.
"clone") the source repository and compile the library by themselves.]
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Next release: 4.0 or 3.5 ?
Posted by sebb <se...@gmail.com>.
On 7 January 2015 at 08:23, luc <lu...@spaceroots.org> wrote:
> Le 2015-01-06 23:13, Gilles a écrit :
>>
>> On Tue, 06 Jan 2015 23:10:33 +0100, Gilles wrote:
>>>
>>> Hi.
>>>
>>> Do we head towards 4.0, starting to implement the dreaded
>>> breakings? ;-)
>
>
>
> +1, +1, +1, +1 !!!
>
> To be serious, yes, we are really stuck by now and several pending
> changes should be done. We talked about fluent API for optimizers
> and it was too much too squeeze without breaking API. I attempted
> the same for ODE, and here again it was postponed as it touched
> user level interfaces.
>
> I would even say that we should from the beginning change the top
> level package name to 4.0 so users can test earlier the changes as
> we prepare the next version, using only one feature at a time and
> preserving the older release for the other features.
That needs to be done carefully to avoid creating jar hell.
What exactly are you proposing here?
Are you referring to SNAPSHOTs only (in which case caution is only advisable)?
If you are proposing to release jars with the new package name, then
this needs to be done in a separate jar with new Maven coords.
It would be possible to gradually add more packages to the new jar as
the original ones are converted.
> best regards,
>
> Luc
>
>
>>
>> I meant
>> s/breaking/cleanup/
>> s/breaking/improvement/
>> of course. :-)
>>
>>
>> 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] Next release: 4.0 or 3.5 ?
Posted by luc <lu...@spaceroots.org>.
Le 2015-01-06 23:13, Gilles a écrit :
> On Tue, 06 Jan 2015 23:10:33 +0100, Gilles wrote:
>> Hi.
>>
>> Do we head towards 4.0, starting to implement the dreaded
>> breakings? ;-)
+1, +1, +1, +1 !!!
To be serious, yes, we are really stuck by now and several pending
changes should be done. We talked about fluent API for optimizers
and it was too much too squeeze without breaking API. I attempted
the same for ODE, and here again it was postponed as it touched
user level interfaces.
I would even say that we should from the beginning change the top
level package name to 4.0 so users can test earlier the changes as
we prepare the next version, using only one feature at a time and
preserving the older release for the other features.
best regards,
Luc
>
> I meant
> s/breaking/cleanup/
> s/breaking/improvement/
> of course. :-)
>
>
> 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] Next release: 4.0 or 3.5 ?
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 06 Jan 2015 23:10:33 +0100, Gilles wrote:
> Hi.
>
> Do we head towards 4.0, starting to implement the dreaded
> breakings? ;-)
I meant
s/breaking/cleanup/
s/breaking/improvement/
of course. :-)
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org