Maven treats 2.0 or 2.0.0 very differently than 2.0.0-rc1. The first is treated as numeric coordinates while the second is just a string. Once we release 2.0 it is unlikely we would have another release with a string in it until perhaps 3.0.
I would not recommend or be in favor of using 2.0.0.RELEASE as Maven coordinates. Ralph > On Mar 2, 2014, at 5:15 PM, Gary Gregory <[email protected]> wrote: > >> On Sun, Mar 2, 2014 at 7:49 PM, Remko Popma <[email protected]> wrote: >> In that case I'd be fine with 2.0.0.RELEASE for the reasons you mentioned. > > This is only for OSGi right? I'd hate to have to use that as Maven coords. > > Gary > >> >> Sent from my iPhone >> >>> On 2014/03/03, at 9:35, Matt Sicker <[email protected]> wrote: >>> >>> 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 <[email protected]> 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 <[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]> >>> >>> >>> >>> -- >>> Matt Sicker <[email protected]> > > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory
