On Fri, 11 Feb 2011 07:19:33 +0100, Torsten Werner wrote:
Hi Thomas,
On Thu, Feb 10, 2011 at 10:23 PM, Thomas Zeeman
wrote:
Actually, you can predict it. Given the above order and no outside
influences like a dependencyManagement block in your (parent) pom, it
would be 0.1. See
http://mave
Hi Thomas,
On Thu, Feb 10, 2011 at 10:23 PM, Thomas Zeeman wrote:
> Actually, you can predict it. Given the above order and no outside influences
> like a dependencyManagement block in your (parent) pom, it would be 0.1. See
> http://maven.apache.org/guides/introduction/introduction-to-depende
On Feb 10, 2011, at 10:40 PM, Jesús M. Navarro wrote:
> Hi, Stefane:
>
> On Thursday 10 February 2011 21:29:34 Stefane Fermigier wrote:
>> On Feb 10, 2011, at 7:50 PM, Russ Allbery wrote:
>>> Stefane Fermigier writes:
Only by fixing version numbers of third-party libraries can you be sure
"Jesús M. Navarro" writes:
> If you don't do that already is because you know that your app will fail
> day-in day-out because foo developer (and bar, and zoot...) is not
> sensible enough not to break backwards compatibility between foo_1.2.3
> and foo_1.2.4. Russ is right in that when things g
Stefane Fermigier writes:
> On Feb 10, 2011, at 7:50 PM, Russ Allbery wrote:
>> For those of us who have been doing this sort of thing for a while,
>> this argument sounds very familiar. I've heard this argument applied
>> to C libraries, Perl modules, Python modules, and most recently Ruby
>> m
Hi, Stefane:
On Thursday 10 February 2011 21:29:34 Stefane Fermigier wrote:
> On Feb 10, 2011, at 7:50 PM, Russ Allbery wrote:
> > Stefane Fermigier writes:
> >> Only by fixing version numbers of third-party libraries can you be sure
> >> that the same build that works today will still work next
On Feb 10, 2011, at 9:38 PM, Torsten Werner wrote:
> Hi Stefane,
>
>
> On Thu, Feb 10, 2011 at 3:25 PM, Stefane Fermigier wrote:
>> Only by fixing version numbers of third-party libraries can you be sure that
>> the same build that works today will still work next week, if you redo the
>> bu
On Feb 10, 2011, at 10:02 PM, Torsten Werner wrote:
> On Thu, Feb 10, 2011 at 9:47 PM, Stefane Fermigier wrote:
>> On Feb 10, 2011, at 9:38 PM, Torsten Werner wrote:
>>> a.jar (0.1) depends on b.jar (0.1)
>>> c.jar (0.3) depends on b.jar (0.2)
>>> d.jar (0.4) depends on a.jar (0.1) and c.jar (0.
On Thu, Feb 10, 2011 at 9:47 PM, Stefane Fermigier wrote:
> On Feb 10, 2011, at 9:38 PM, Torsten Werner wrote:
>> a.jar (0.1) depends on b.jar (0.1)
>> c.jar (0.3) depends on b.jar (0.2)
>> d.jar (0.4) depends on a.jar (0.1) and c.jar (0.3)
>
> A lot of things are wrong in Maven, but it this case,
On Feb 10, 2011, at 9:38 PM, Torsten Werner wrote:
> Hi Stefane,
>
>
> On Thu, Feb 10, 2011 at 3:25 PM, Stefane Fermigier wrote:
>> Only by fixing version numbers of third-party libraries can you be sure that
>> the same build that works today will still work next week, if you redo the
>> bu
Hi Stefane,
On Thu, Feb 10, 2011 at 3:25 PM, Stefane Fermigier wrote:
> Only by fixing version numbers of third-party libraries can you be sure that
> the same build that works today will still work next week, if you redo the
> build on the exact same version of the sources (and Maven, and Jav
On Feb 10, 2011, at 7:50 PM, Russ Allbery wrote:
> Stefane Fermigier writes:
>
>> Only by fixing version numbers of third-party libraries can you be sure
>> that the same build that works today will still work next week, if you
>> redo the build on the exact same version of the sources (and Mav
Stefane Fermigier writes:
> Only by fixing version numbers of third-party libraries can you be sure
> that the same build that works today will still work next week, if you
> redo the build on the exact same version of the sources (and Maven, and
> Java, of course), any operating system.
> Yes,
On Feb 10, 2011, at 2:49 PM, Thomas Koch wrote:
> Hi Stefane,
>
> in another thread you write:
>
>>> and that it is possible for projects to accumulate
>>> technical debt by depending on strict version numbers.
>>
>> OTOH, this is a HUGE source of instability and hard to debug bugs (as we've
Hi Stefane,
in another thread you write:
> > and that it is possible for projects to accumulate
> > technical debt by depending on strict version numbers.
>
> OTOH, this is a HUGE source of instability and hard to debug bugs (as we've
found to our expense) to depend on loose version numbers.
I
15 matches
Mail list logo