Alright, I know I've brought this up a couple times, but this is also based on new information I've learned about the esoteric rules behind versioning in OSGi (which I'm pretty sure also applies to Maven; however, most people don't use version number ranges in Maven dependencies).
Here's everything you need to know about how version numbers are interpreted by these different build systems. As expected, a version number is in the form X.Y.Z.Description, although not all fields are required. X, or "major", is the only required one, and version 2 is equivalent to 2.0 as well as 2.0.0. However, that description part at the end adds a further version number, and that one is compared lexicographically. This means that 2.0.0.beta1 comes after 2.0.0.alpha4, but it ALSO means that 2.0.0.alpha1 is considered _newer_ than 2.0.0. Yeah, that's right. Now I see why some projects like Spring tend to use the scheme 4.0.2.RELEASE; RELEASE comes after alpha, beta, RC, prerelease, or practically any other naming scheme. If you don't use RC versions, then FINAL or GA are also fine choices. That being said, because we've released 2.0.0.RC1 et al., the most effective way to enforce the release version of 2.0.0 to be considered the newest 2.0.0 release would be naming it something like 2.0.0.RELEASE. A real cheap way to bypass that is releasing it as version 2.0.1, but then the version numbers get out of sync right away. Unless someone has a fun release name that comes late in the alphabet like ZETA or something. That would solve any potential naming problems rather effectively. I don't know what the exact details are for Maven/Ivy/Gradle/etc. version number interpretation, but I'm pretty sure it follows almost the same exact standard, but with less stringent requirements on how the part after X.Y.Z looks (e.g., you can use dashes instead, or your entire version number could be a single number like a build date). It does, however, seem to use lexicographical ordering when comparing version numbers like 2.0.0-beta4 versus 2.0.0-rc1. This can lead to some unexpected results if you specify, let's say, log4j-api version [2.0,3.0), if your repository has non-release versions in the releases section. NB: I'm a bit of a nerd about versioning. -- Matt Sicker <boa...@gmail.com>
