Version policy changes starting from 2.4?

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Version policy changes starting from 2.4?

Daniel Dekany
I just copy-paste what you could see in the SVN log... Tell me if you
agree or not:

# Version number
# --------------
#
# The version number format is (since FreeMarker 2.4.0):
#
#   Version ::= major '.' minor '.' micro ('.' Qualifier)?
#   Qualifier :: = ( ('pre'|'rc') positiveInteger '-snapshot'? )
#
# Note that this format is OSGi-compatible, and it must remain that.
#
# Examples:
#   Version number        Means
#   3.0.0                 3.0.0 stable release
#   3.3.12                3.3.12 stable release
#   3.3.13.snapshot       Modified "nightly" version just after 3.3.12,
#                         which will become to 3.3.13 one day.
#   3.4.0.pre13           The 13th preview of version "3.3.0"
#   3.4.0.pre14-snapshot  Unreleased nightly version of the yet unfinished
#                         3.3.0.pre14.
#   3.4.0.rc1             1st release candidate of "3.4"
#   3.4.0                 3.4.0 stable release
#
# Backward-compatibility policy (since FreeMarker 2.4.0):
# - When only the micro version number is increased, full backward
#   compatibility is expected (ignoring cases where code depends on
#   "features" that are obviously implementation bugs).
# - When the minor version number is increased, some minor backward
#   compatibility violations are allowed. Most dependent code should
#   continue working without modification or recompilation.
# - When the major version number is increased, major backward
#   compatibility violations are allowed.
version=3.0.0.pre2-snapshot

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Version policy changes starting from 2.4?

Guo Du-4
On Thu, Jul 8, 2010 at 1:33 PM, Daniel Dekany <[hidden email]> wrote:
> #   3.3.12                3.3.12 stable release
> #   3.3.13.snapshot       Modified "nightly" version just after 3.3.12,
> #                         which will become to 3.3.13 one day.
The version 3.3.13.snapshot may released as 3.3.13+ such as 3.3.14.

As some of version compare logic (e.g. string compare) may think
3.3.13.snapshot is newer than 3.3.13

Just a minor concern.

-Guo

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Version policy changes starting from 2.4?

Daniel Dekany
In reply to this post by Daniel Dekany
Because I know that everybody is so interested in this topic... ;)
I changed the system a bit more, because OSGi sorted the version badly
otherwise:

#   Version ::= major '.' minor '.' micro '.' Qualifier
#   Qualifier :: = 'stable'
#                  | 'nightly'
#                  | ( ('pre'|'rc') twoDigitPositiveInteger '-nightly'? )
#
# Note that this format is OSGi-compatible, and it must remain so.
# Also note that OSGi compares version qualifiers with String.compareTo,
# thus "nightly" < "pre" < "rc" < "stable", etc.
#
# Examples:
#   Version number        Means
#   3.0.0.stable          3.0.0 final release
#   3.3.12.stable         3.3.12 final release
#   3.3.13.nightly        Modified version after 3.3.12.stable, which will
#                         become to 3.3.13.stable one day.
#   3.4.0.pre03           The 3rd preview of version 3.3.0
#   3.4.0.pre04-nightly   Unreleased nightly version of the yet unfinished
#                         3.3.0.pre04.
#   3.4.0.rc01            1st release candidate of 3.4.0

--
Best regards,
 Daniel Dekany


Thursday, July 8, 2010, 2:33:22 PM, Daniel Dekany wrote:

> I just copy-paste what you could see in the SVN log... Tell me if you
> agree or not:
>
> # Version number
> # --------------
> #
> # The version number format is (since FreeMarker 2.4.0):
> #
> #   Version ::= major '.' minor '.' micro ('.' Qualifier)?
> #   Qualifier :: = ( ('pre'|'rc') positiveInteger '-snapshot'? )
> #
> # Note that this format is OSGi-compatible, and it must remain that.
> #
> # Examples:
> #   Version number        Means
> #   3.0.0                 3.0.0 stable release
> #   3.3.12                3.3.12 stable release
> #   3.3.13.snapshot       Modified "nightly" version just after 3.3.12,
> #                         which will become to 3.3.13 one day.
> #   3.4.0.pre13           The 13th preview of version "3.3.0"
> #   3.4.0.pre14-snapshot  Unreleased nightly version of the yet unfinished
> #                         3.3.0.pre14.
> #   3.4.0.rc1             1st release candidate of "3.4"
> #   3.4.0                 3.4.0 stable release
> #
> # Backward-compatibility policy (since FreeMarker 2.4.0):
> # - When only the micro version number is increased, full backward
> #   compatibility is expected (ignoring cases where code depends on
> #   "features" that are obviously implementation bugs).
> # - When the minor version number is increased, some minor backward
> #   compatibility violations are allowed. Most dependent code should
> #   continue working without modification or recompilation.
> # - When the major version number is increased, major backward
> #   compatibility violations are allowed.
> version=3.0.0.pre2-snapshot
>


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Version policy changes starting from 2.4?

Daniel Dekany
In reply to this post by Guo Du-4
Thursday, July 8, 2010, 4:05:37 PM, Guo Du wrote:

> On Thu, Jul 8, 2010 at 1:33 PM, Daniel Dekany <[hidden email]> wrote:
>> #   3.3.12                3.3.12 stable release
>> #   3.3.13.snapshot       Modified "nightly" version just after 3.3.12,
>> #                         which will become to 3.3.13 one day.
> The version 3.3.13.snapshot may released as 3.3.13+ such as 3.3.14.
>
> As some of version compare logic (e.g. string compare) may think
> 3.3.13.snapshot is newer than 3.3.13
>
> Just a minor concern.

Funny you mention that, as I just fixed this minutes ago... now it
would be 3.3.13.stable, which is greater than 3.3.13.nightly (because
's' is greater than 'n').

> -Guo

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Version policy changes starting from 2.4?

Guo Du-4
On Thu, Jul 8, 2010 at 7:59 PM, Daniel Dekany <[hidden email]> wrote:
> Funny you mention that, as I just fixed this minutes ago... now it
> would be 3.3.13.stable, which is greater than 3.3.13.nightly (because
> 's' is greater than 'n').
You may have whatever qualifier for unstable release such as RC,
SNAPSHOTS, ALPHA, BETA, but for stable release, would prefer to just
have numbers as what FM current have.

-Guo

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Version policy changes starting from 2.4?

Daniel Dekany
Thursday, July 8, 2010, 11:47:46 PM, Guo Du wrote:

> On Thu, Jul 8, 2010 at 7:59 PM, Daniel Dekany <[hidden email]> wrote:
>> Funny you mention that, as I just fixed this minutes ago... now it
>> would be 3.3.13.stable, which is greater than 3.3.13.nightly (because
>> 's' is greater than 'n').
> You may have whatever qualifier for unstable release such as RC,
> SNAPSHOTS, ALPHA, BETA, but for stable release, would prefer to just
> have numbers as what FM current have.

Aesthetically that's understandable... But what can I do, if for OSGi
"1.2.3.something" is greater than "1.2.3"? And of course, the version
number will be like "1.2.3" everywhere except for OSGi (and according
to what `java -jar freemarker.jar` prints). One could say that this
will be annoying exactly when using OSGi, as a dependency with version
"[1.2.3,1.2.3]" will not match "1.2.3.stable" (but "1.2.3" or
"[1.2.3,3.0.0)" would). But then, I saw that Eclipse guys (who are
very prominent OSGi users) use bundle version numbers like
"1.2.3.i20100709", which poses the same problem... /-: So I don't know
what to think. Either the sorting will be wrong, or exact matches will
be tricky... which finger will we bite?

> -Guo

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Version policy changes starting from 2.4?

Daniel Dekany
Friday, July 9, 2010, 12:31:44 AM, Daniel Dekany wrote:

> Thursday, July 8, 2010, 11:47:46 PM, Guo Du wrote:
>
>> On Thu, Jul 8, 2010 at 7:59 PM, Daniel Dekany <[hidden email]> wrote:
>>> Funny you mention that, as I just fixed this minutes ago... now it
>>> would be 3.3.13.stable, which is greater than 3.3.13.nightly (because
>>> 's' is greater than 'n').
>> You may have whatever qualifier for unstable release such as RC,
>> SNAPSHOTS, ALPHA, BETA, but for stable release, would prefer to just
>> have numbers as what FM current have.
>
> Aesthetically that's understandable... But what can I do, if for OSGi
> "1.2.3.something" is greater than "1.2.3"? And of course, the version
> number will be like "1.2.3" everywhere except for OSGi (and according
> to what `java -jar freemarker.jar` prints). One could say that this
> will be annoying exactly when using OSGi, as a dependency with version
> "[1.2.3,1.2.3]" will not match "1.2.3.stable" (but "1.2.3" or
> "[1.2.3,3.0.0)" would). But then, I saw that Eclipse guys (who are
> very prominent OSGi users) use bundle version numbers like
> "1.2.3.i20100709", which poses the same problem... /-: So I don't know
> what to think. Either the sorting will be wrong, or exact matches will
> be tricky... which finger will we bite?

BTW, Spring guys also use funny qualifiers, pretty much like I did here:
http://www.springsource.com/repository/app/faq#q12

However, that this generated a FAQ also means something... :)
(I wonder what did all the companies behind OSGi think about this.
They never heard about milestone releases, RC-s and so on? Or do they
really wanted people to chose qualifier names that happen to be both
meaningful and alphabetical ordered correctly?)


>> -Guo
>

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Version policy changes starting from 2.4?

Guo Du-4
In reply to this post by Daniel Dekany
On Thu, Jul 8, 2010 at 11:31 PM, Daniel Dekany <[hidden email]> wrote:

> Aesthetically that's understandable... But what can I do, if for OSGi
> "1.2.3.something" is greater than "1.2.3"? And of course, the version
> number will be like "1.2.3" everywhere except for OSGi (and according
> to what `java -jar freemarker.jar` prints). One could say that this
> will be annoying exactly when using OSGi, as a dependency with version
> "[1.2.3,1.2.3]" will not match "1.2.3.stable" (but "1.2.3" or
> "[1.2.3,3.0.0)" would). But then, I saw that Eclipse guys (who are
> very prominent OSGi users) use bundle version numbers like
> "1.2.3.i20100709", which poses the same problem... /-: So I don't know
> what to think. Either the sorting will be wrong, or exact matches will
> be tricky... which finger will we bite?
Hi Daniel, real life is complicated :)

There are two version mechanism for jar distribution and OSGi. e.g. we may have:
org.foo.bar-1.2.3.i20100709.jar
org.foo.bar.zoo;version="[1.2.0, 1.3.0)"

In general practice, OSGi version set the major and minor field. And
assume micro versions are compatible.

-Guo

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Version policy changes starting from 2.4?

Daniel Dekany
Friday, July 9, 2010, 1:04:03 AM, Guo Du wrote:

> On Thu, Jul 8, 2010 at 11:31 PM, Daniel Dekany <[hidden email]> wrote:
>> Aesthetically that's understandable... But what can I do, if for OSGi
>> "1.2.3.something" is greater than "1.2.3"? And of course, the version
>> number will be like "1.2.3" everywhere except for OSGi (and according
>> to what `java -jar freemarker.jar` prints). One could say that this
>> will be annoying exactly when using OSGi, as a dependency with version
>> "[1.2.3,1.2.3]" will not match "1.2.3.stable" (but "1.2.3" or
>> "[1.2.3,3.0.0)" would). But then, I saw that Eclipse guys (who are
>> very prominent OSGi users) use bundle version numbers like
>> "1.2.3.i20100709", which poses the same problem... /-: So I don't know
>> what to think. Either the sorting will be wrong, or exact matches will
>> be tricky... which finger will we bite?
> Hi Daniel, real life is complicated :)

Especially since the wise people who design all these standards make
it so...

> There are two version mechanism for jar distribution and OSGi. e.g. we may have:
> org.foo.bar-1.2.3.i20100709.jar
> org.foo.bar.zoo;version="[1.2.0, 1.3.0)"
>
> In general practice, OSGi version set the major and minor field. And
> assume micro versions are compatible.

Yes, that's why I have chosen 1.2.3.stable variation. However, I think
Configuration.getVersionNumber() should reformat it so that the
".stable" prefix will not be there.

> -Guo

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Version policy changes starting from 2.4?

Guo Du-4
On Fri, Jul 9, 2010 at 9:57 AM, Daniel Dekany <[hidden email]> wrote:
> Yes, that's why I have chosen 1.2.3.stable variation. However, I think
> Configuration.getVersionNumber() should reformat it so that the
> ".stable" prefix will not be there.
Configuration.getVersionNumber() should return whatever version of the
jar you want to be. If you have .stable, then it should be there. I
don't think it give any extra benefit to introduce another version
other than confuse people and give extra work for you.

Still prefer not use qualifier if possible, then we don't have those Q&A.

-Guo

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Version policy changes starting from 2.4?

Daniel Dekany
Friday, July 9, 2010, 11:32:38 AM, Guo Du wrote:

> On Fri, Jul 9, 2010 at 9:57 AM, Daniel Dekany <[hidden email]> wrote:
>> Yes, that's why I have chosen 1.2.3.stable variation. However, I think
>> Configuration.getVersionNumber() should reformat it so that the
>> ".stable" prefix will not be there.
> Configuration.getVersionNumber() should return whatever version of the
> jar you want to be. If you have .stable, then it should be there. I
> don't think it give any extra benefit to introduce another version
> other than confuse people and give extra work for you.

Yeah, maybe...

> Still prefer not use qualifier if possible, then we don't have those Q&A.

I don't know what to prefer... What do other projects do with the RC-s
and like? /-: I mean, apart for doing the same things as I did (see
Spring). Some of these non-stable releases are accessible for the
public, are used, etc., so an RC should win over the final release.

> -Guo

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Version policy changes starting from 2.4?

Daniel Dekany
Friday, July 9, 2010, 11:32:57 PM, Daniel Dekany wrote:

> Friday, July 9, 2010, 11:32:38 AM, Guo Du wrote:
>
>> On Fri, Jul 9, 2010 at 9:57 AM, Daniel Dekany <[hidden email]> wrote:
>>> Yes, that's why I have chosen 1.2.3.stable variation. However, I think
>>> Configuration.getVersionNumber() should reformat it so that the
>>> ".stable" prefix will not be there.
>> Configuration.getVersionNumber() should return whatever version of the
>> jar you want to be. If you have .stable, then it should be there. I
>> don't think it give any extra benefit to introduce another version
>> other than confuse people and give extra work for you.
>
> Yeah, maybe...
>
>> Still prefer not use qualifier if possible, then we don't have those Q&A.
>
> I don't know what to prefer... What do other projects do with the RC-s
> and like? /-: I mean, apart for doing the same things as I did (see
> Spring). Some of these non-stable releases are accessible for the
> public, are used, etc., so an RC should win over the final release.

I mean "should NOT win" of course...

>> -Guo
>

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Version policy changes starting from 2.4?

Guo Du-4
In reply to this post by Daniel Dekany
On Fri, Jul 9, 2010 at 10:32 PM, Daniel Dekany <[hidden email]> wrote:
> Friday, July 9, 2010, 11:32:38 AM, Guo Du wrote:
>> Still prefer not use qualifier if possible, then we don't have those Q&A.
> I don't know what to prefer... What do other projects do with the RC-s
> and like? /-: I mean, apart for doing the same things as I did (see
> Spring). Some of these non-stable releases are accessible for the
> public, are used, etc., so an RC should win over the final release.

None stable should be released in different channel/repository for
early adapters. Spring follow this practice:
https://s3browse.springsource.com/browse/maven.springframework.org/

And only 3.0 stable release in central maven repository for public:
http://repo2.maven.org/maven2/org/springframework/spring-core/

Strange thing is that spring stable release has .RELEASE surfix which
I don't think make sense.

-Guo

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Version policy changes starting from 2.4?

Daniel Dekany
Saturday, July 10, 2010, 12:27:05 AM, Guo Du wrote:

> On Fri, Jul 9, 2010 at 10:32 PM, Daniel Dekany <[hidden email]> wrote:
>> Friday, July 9, 2010, 11:32:38 AM, Guo Du wrote:
>>> Still prefer not use qualifier if possible, then we don't have those Q&A.
>> I don't know what to prefer... What do other projects do with the RC-s
>> and like? /-: I mean, apart for doing the same things as I did (see
>> Spring). Some of these non-stable releases are accessible for the
>> public, are used, etc., so an RC should win over the final release.
>
> None stable should be released in different channel/repository for
> early adapters. Spring follow this practice:
> https://s3browse.springsource.com/browse/maven.springframework.org/
>
> And only 3.0 stable release in central maven repository for public:
> http://repo2.maven.org/maven2/org/springframework/spring-core/

In the case of FM, the Maven repository (which is the Maven Central
Repository) only contains the stable releases anyway. OSGi itself has
no standard repository mechanism. Still, there is *some* risk of
having non-stable releases around, as preview and RC releases are
promoted and can be downloaded on our website and from sf.net download
page.

> Strange thing is that spring stable release has .RELEASE surfix which
> I don't think make sense.

They also have .M suffix for milestones, .RC suffix for RC-s, etc.
Their reason is the same as mine: 1.2.3 would be less than 1.2.3.RC,
but 1.2.3.RELEASE is greater because 'E' > 'C'. (Also note that
Eclipse-related OSGi bundles always use qualifiers too.) I'm not
convicted at all that *for OSGi* this is not the better practice.
Looks ugly but at least it's technically correct. (Also note that
Eclipse-related bundles also almost always use a date as a qualifier,
so OSGi versions look ugly there too.)

Speaking of Maven, there the stable releases should not have a
qualifier (because there a version number without qualifier is
considered to be greater than the same version number with a
qualifier). Also in Maven the qualifier must be preceded with a '-',
not a '.'. So it sounds like we need two kind of version number
anyway. OK, we actually don't have previews and RC-s in any Maven
repos, but still... this is how it's round. So we could use the Maven
version number everywhere (like for Configuration.getVersionNumber()),
except in the bundles, where unfortunately the uglier OSGi version
number must be used. How about that? /-:

> -Guo

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Version policy changes starting from 2.4?

Daniel Dekany
Saturday, July 10, 2010, 9:58:16 AM, Daniel Dekany wrote:

> Saturday, July 10, 2010, 12:27:05 AM, Guo Du wrote:
[snip]

> Speaking of Maven, there the stable releases should not have a
> qualifier (because there a version number without qualifier is
> considered to be greater than the same version number with a
> qualifier). Also in Maven the qualifier must be preceded with a '-',
> not a '.'. So it sounds like we need two kind of version number
> anyway. OK, we actually don't have previews and RC-s in any Maven
> repos, but still... this is how it's round. So we could use the Maven
> version number everywhere (like for Configuration.getVersionNumber()),
> except in the bundles, where unfortunately the uglier OSGi version
> number must be used. How about that? /-:

JSR 277 (Java module system), which meant to be the part of Java 7,
uses Maven-ish version comparison, means, 1.2.3 is greater than
1.2.3-something. Also, it uses '-' before qualifiers, just like Maven.
Thus, the OSGi version number will only be a secondary thing (with the
.stable postfix, to support OSGi's oddity in this regard) and the
version number used everywhere but in OSGi metadata will be one that's
both Maven and JSR 277 compliant. (I realize that the JSR is an early
draft, but I think it's a safe bet that it will be like I said.)

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel