logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: We need to discuss version names for OSGi one last time.
Date Mon, 03 Mar 2014 02:10:22 GMT
I think we could just add .RELEASE to the OSGi version in the manifest.

On 2 March 2014 19:56, Ralph Goers <rgoers@apache.org> wrote:

> 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 <garydgregory@gmail.com> wrote:
> On Sun, Mar 2, 2014 at 7:49 PM, Remko Popma <remko.popma@gmail.com> 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 <boards@gmail.com> 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 <remko.popma@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 <boards@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 <boards@gmail.com>
>> --
>> Matt Sicker <boards@gmail.com>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

Matt Sicker <boards@gmail.com>

View raw message