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 <s...@nuxeo.com> 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, we do upgrade third-party lib versions from time to time, but only
> >> when there is a good reason to ("if it ain't broke, don't fix it").
> >>
> >> BTW: I used to think like you 3-4 years ago when I discovered Maven, but
> >> had to change my mind due to the reality.
> >
> > 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 modules.
> > It always sounds persuasive when presented from a stability perspective.
> > It has always proven to be completely wrong in the long run.
>
> Please develop, unless you want me to believe you only based on your
> reputation, which I won't since I don't know you.
I'll give my opinion here: both Russ and you are right.
Yes, you are right: in order to distribute a product you must have to be able
to reproduce it unambiguosly from your sources. This implies all your
dependencies must be hardcoded.
But in the case of Java (and Ruby, and Python), making this on development is
nothing but a dirty hack to cover the malpractices of the developers.
Your development environment should rely at most on minor versions of its
dependencies and let the extraversion float as the upstream developer see fit
because said upstream developer will have the acumen not to break backwards
compatibility between extraversions and, in fact, will use extraversions only
for bug fixing (and those you definetly want as soon as they are published).
Your developers, on the other hand, will need to defend their position if
your app is happening to be using two different versions of the same
component and, no, telling "that's what X-tool pushed into my environment",
or "that's the uberbleeding edge version from the upstream developer out of
his nightly builds" is not a proper answer.
So, if your app depends on, say, foo_1.2.3, your dependency checking will look
for foo_1.2 or even "just" for foo_1. This will allow your continous
building environment to fail early if it happens that foo_1.2.(x+1) or foo_1.
(x+1) are not backwards compatible, analyze why and act accordingly. Of
course, once the shinny new version of your app is ready, you will freeze
your building environment for that version to whatever happens to be the
exact versions of dependant libs at the moment.
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 go that way, things are completly wrong in
the long run in so many manners it's not even funny. The fact this behaviour
is "business as usual" on Java development it's only a measure of its average
quality.
Oh! and another hint: "if ain't broken don't fix it" is not such a valuable
knowledge with regards to open source if only because of the outer testing
base and the work it takes to jump over more than a few releases
(exponential, not linear, to the distance).
Cheers.
--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201102102240.15157.jesus.nava...@undominio.net
