You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Matt Sicker <bo...@gmail.com> on 2014/03/02 22:56:10 UTC
We need to discuss version names for OSGi one last time.
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 <bo...@gmail.com>
Re: We need to discuss version names for OSGi one last time.
Posted by Matt Sicker <bo...@gmail.com>.
I think we could just add .RELEASE to the OSGi version in the manifest.
Simple.
On 2 March 2014 19:56, Ralph Goers <rg...@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 <ga...@gmail.com> wrote:
>
> On Sun, Mar 2, 2014 at 7:49 PM, Remko Popma <re...@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 <bo...@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 <re...@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 <bo...@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 <bo...@gmail.com>
>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@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 <bo...@gmail.com>
Re: We need to discuss version names for OSGi one last time.
Posted by Ralph Goers <rg...@apache.org>.
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 <ga...@gmail.com> wrote:
>
>> On Sun, Mar 2, 2014 at 7:49 PM, Remko Popma <re...@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 <bo...@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 <re...@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 <bo...@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 <bo...@gmail.com>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> 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
Re: We need to discuss version names for OSGi one last time.
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, Mar 2, 2014 at 7:49 PM, Remko Popma <re...@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 <bo...@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 <re...@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 <bo...@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 <bo...@gmail.com>
>>
>>
>
>
> --
> Matt Sicker <bo...@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
Re: We need to discuss version names for OSGi one last time.
Posted by Remko Popma <re...@gmail.com>.
In that case I'd be fine with 2.0.0.RELEASE for the reasons you mentioned.
Sent from my iPhone
> On 2014/03/03, at 9:35, Matt Sicker <bo...@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 <re...@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 <bo...@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 <bo...@gmail.com>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: We need to discuss version names for OSGi one last time.
Posted by Matt Sicker <bo...@gmail.com>.
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 <re...@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 <bo...@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 <bo...@gmail.com>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: We need to discuss version names for OSGi one last time.
Posted by Remko Popma <re...@gmail.com>.
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 <bo...@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 <bo...@gmail.com>