Right. You can specify this all as metadata. It's easier to use the same version number as the Maven artefacts, but it doesn't have to be the same at all.
On 2 March 2014 18:16, Remko Popma <remko.po...@gmail.com> wrote: > 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 <boa...@gmail.com> 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 <boa...@gmail.com> > > -- Matt Sicker <boa...@gmail.com>
