On 7/24/20 1:04 AM, Stefan Bodewig wrote:
Hi all
here I'd like to explain why I prefer not to update dependencies just
because we can. Maybe you can convince me that I'm wrong. I've tried to
make this point in different threads but either it has been lost or it
just wasn't worth discussing.
First of all let me get a few things out of the way
* I'm not talking about emails, I can deal with them
* I don't care whether a bot or a human asks for a version update
* I'm only talking about dependencies that are visible to our
users. Test time dependencies or versions of Maven plugins are
probably not an issue. Although Compress has mananaged to break its
OSGi bundle just by upgrading the parent POM in the past.
https://issues.apache.org/jira/browse/COMPRESS-498
All our components have downstream users. I.e. our dependencies become
somebody else's dependencies as well.
Let's say commons-foo 1.1.0 depends on A 1.12.4 and bumps the dependency
to A 1.12.18 for commons-foo 1.2.0.
When a user of commons-foo upgrades to 1.2.0 and hasn't defined their
dependency on A explicitly they will also upgrade A to 1.12.18. This may
be fine or it may cause problems. The new version of A may have made
incompatible changes that break the user's code or it may just have bugs
that were not present in A 1.12.4 and now raise their head.
Of course the users can explicitly state a dependency on A 1.12.4
themselves. But there is no guarantee commons-foo compiled against A
1.12.18 will still work with A 1.12.4.
About fifteen years ago Ant was bitten by StringBuffer adding a new
method append(StringBuffer) in Java 1.4 (if memory serves me
right). Code that called someStringBuffer.append(anotherStringBuffer)
compiled on Java 1.3 would call append(Object), but compiled on 1.4 it
would call the new version and thus could not run on Java 1.3. This is
the kind of change animal sniffer was invented to detect and the
--release option of javac deals with. There is no such tool helping us
with APIs that are not part of the Java classlib.
Therefore I believe updating a dependency is a risk and we should leave
it to the users to decide which version they want to use.
Unless we've got real reasons to update. Real reasons IMHO are security
issues, bugs in dependencies causing bugs in our code or when we really
want to use new features introduced in a new version.
+1
Above seems a good list of reasons to me.
I would also add that we should try as much as possible to avoid
dependencies in Commons components. There is no need to update
dependencies that don't exist :) I agree with Gary though that shading
/ pasting should not be used to avoid dependencies in Commons
components. Some can't avoid having dependencies. When they do, I
think your criteria for when to update is good.
I agree strongly with the point you make below about the need to care
more about our downstream users than ourselves or upstream. If we pass
too many regression or compatibility bugs forward, we will eventually
lose the former, which makes our components kind of pointless.
I also agree with your view on automatic transitive dependency
resolution. Violates what I call the law of conservation of real work.
But that ship has sailed...
Phil
Outside of these good reasons I wouldn't want to ever update a
dependency.
Stefan
---------------------------------------------------------------------
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
