Hi All: I'd like to start here by flipping the story around by looking at what we do.
Ideally, a PR comes in for a bug with its fix and unit test. This is the best case scenario. If the PR is green, we squash and merge, and tell folks, yes, it will be in the next release. At times, a message comes in that says something like "In version 1.1, I see this behavior, it's a bug!" To which we say, "Ah, yes, this was fixed in 1.5, please upgrade." Alternatively, we say "Ah, yes, that's a bug, may you provide a PR? It will be in the next release". Other times, we say "May you please try the latest version, see what happens, and tell us?" Then pick one of the above. Sometime I say: "I'm not going to fix this on top of 1.1 to create a 1.1.1, I'll fix it in the current code base and it will be in the next version." A CVE might cause an older version to be branched as in the 1.1.1 case above but I've not seen that done here. Now back to our code depending on other dependencies. My view is that there are bugs, you just have not hit them. If I find one in a dependency and it gets fixed, it's going to mean a new version of that dependency. Furthermore, when I look online for Javadoc and examples, if I use a current jar version, then my odds are better that I can implement what I find online. I view it as simpler and safer to update from a "near" dependency than letting a dependency acquire "bit rot" and upgrade later, especially if an update means making adjustments. I want to make smaller increments of adjustment rather than a larger set. Just like I prefer to RERO instead of big bangs for releasing Commons components. Another way to look at this is to look at a large software stack: If every library developer never updates dependencies, then your application, through transitive dependencies will end up depending (virtually) on many versions of the each library, which is much more likely to create jar hell and other problems than the other edge case where everyone uses the latest version (or a fixed version.) >From a hand-waving-talking-over-beers-more-FOSS-y philosophical-POV, I'd like to think that by eating our own current Apache dog food as well as other FOSS dog food, we all help each other make our software better. Gary On Fri, Jul 24, 2020 at 4:04 AM Stefan Bodewig <bode...@apache.org> 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. > > 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 > >
