To clarify, whatever we decide on the OSGi version number string *only* affects the value for an OSGi-specific attribute in the manifest, right? (Not sure if this attribute exists in the manifest for all jar files or only for the OSGi ones.)
So it doesn't affect the jar/zip file names. Correct? Sent from my iPhone > On 2014/03/03, at 6:56, Matt Sicker <[email protected]> wrote: > > 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 <[email protected]>
