Ever heard the phrase Release Early, Release Often? Have you ever
considered that the most important word in that sentence (from a Bayesian
point of view as well as my own ;-)) is Release?

As noted in by Morgan
Delagrange, Maven makes it very easy to add dependencies to weird
versions of other projects.

In particular, I see an increasing number of open source Java projects
that rely on CVS version (i.e. unreleased) of the code from other
projects.

I think it is really important not to do this. Ignoring the fact that
unreleased code is – well – unreleased – it also dramatically increases
the likely hood of dependency conflicts.

Unfortunately a lot of the jars in the Maven repository do not follow this
practice, and there does not seem to be significant social pressure to stop
people uploading and using random jar versions. For example at the time of
writing Maven itself has 24 dependencies – 6 of which are obviously CVS
builds. A further 8 are marked “dev” or “beta” which probably means they are
actual releases, so I don't necessarily have an issue with those ones (See
http://maven.apache.org/dep
endencies.html).

Perhaps a contributing factor to this problem is the fact that some
projects make very infrequent public releases. That makes it difficult for
other projects to pick up critical bug fixes or new features without using a
CVS version. I've seen projects that had an active development community,
had plenty of other projects using their libraries and yet didn't release a
new version of their library for over a year. I'm pretty sure I saw a tool
that measured how much code had changed between a local copy of some code
and a CVS label – something that is useful to keep an eye on for each of
your dependencies.

See http://jakarta.apac
he.org/commons/versioning.html for a decent guide to how versioning
should be done.

I guess I shouldn't be too critical of Maven. Build management is a topic
which is very easy to have an opinion about, but incredibly hard to
actually do right. To the best of my knowledge Maven is the most successful
and most widely deployed build management tool around, and I think it is a
very impressive piece of work.