On 28/09/2012 10:31 AM, Graham Leggett wrote:
On 28 Sep 2012, at 4:13 PM, Jesse Long <j...@unknown.za.net> wrote:
My library does clearly document the versions of slf4j it depends on - as a
version range in the pom.xml file. How else?
If you are selling or distributing your product, it should be front and
center in your user documentation.
*NOTE: This package will not run with any version of slf4j later than
1.5.11.*
Practically no one reads poms of libraries that they use as
dependencies. Documentation - yes; POMs - no.
Without that warning, I would simply exclude your transitive
dependencies and put in the version of slf4j that we support officially
for our builds and be pissed when I figured out that your code was tied
in some way to an obsolete version of slf4j without a *BIG* warning.
When one builds big projects, there are lots of different versions of
common libraries called up.
If you are watching your dependencies carefully, you look at the
dependency tree and graph and decide which version to run and exclude
the transitive dependencies on artifacts that call up versions that you
do not want to run.
Never mind slf4j for the time being, this affects all libraries.
slf4j is probably pretty benign but my distress would be much greater
for other libraries that would affect the actual results produced.
Please see http://semver.org/
The whole purpose of having a major version number is to clearly indicate when
incompatibility is introduced. It does get introduced, often.
Not acceptable. If a developer is not going to provide upward
compatibility, then they should change the Artifact id to be sure that
no one gets hurt because of the laziness or lack of thoughtfulness or
just plain bad design of the older version.
Major versions are not incompatible in most libraries.
Hibernate is a good example where the developers realized that version 3
was completely different from versions.
If they wanted to have reasonably method names without the danger of
people getting hurt by trying to run code written to version 2 specs
against version 3, they had to rename the artifacts.
In turn, this is why maven goes on about repeatability - so that when you need
to rebuild your code in an emergency to apply that critical bug fix to live,
your code builds first time, every time.
If you're someone like Redhat, and can hire a bunch of people to release
packages with dependencies that follow the rule that ABI compatibility is
maintained at all times, then you're fine. But if you're depending on various
libraries released by various independent people and organisations with no
guarantees of anything, then pinning the version numbers is the only sane thing
to do.
Agreed.
And you might want to warn your users about the bad things that will
happen because of a problem in a transitive dependency even if it is not
your fault.
Regards,
Graham
--
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
