Hi,
 
As someone who has only been following this project for a short amount of time 
I think before a release is done a better sample application needs to be 
produced along with some documentation that explains how web development with 
Sling differs to traditional web development.  
 
Rob

________________________________

From: Felix Meschberger [mailto:[EMAIL PROTECTED]
Sent: Mon 7/01/2008 5:26 AM
To: sling-dev@incubator.apache.org
Subject: Re: Thoughts towards an initial release



Hi,

The OSGi core spec defines the Version as a quadruple 1.2.3.string. The
first three parts are numeric and called major, minor and micro version
number. The fourth part is a string (with a limited character set) which
is called the qualifier.

Version comparison is in terms of comparing each version part to each
other. The numeric parts are compared as would be expected. The
qualifier part is compared with string comparsion, where of course "" is
smaller than "SNAPSHOT".

This is where the problem starts: The (per maven) released version 2.0.0
is actually smaller than 2.0.0.SNAPSHOT in OSGi terms. That means, a
SNAPSHOT version will always be considered more recent in OSGi term than
the corresponding released version.

That is why I suggest this seemingly odd micro version flipping.

Hope this helps clarifying.

Regards
Felix


Am Freitag, den 04.01.2008, 12:03 -0800 schrieb Padraic Hannon:
> I only have a couple comments based on the wiki and email threads.
>
>  > The Apache Felix Maven Bundle Plugin we use to build the Sling 
> bundles converts Maven version numbers
>  > to correct OSGi version numbers. For example, the version 2.0.0-
> incubator-SNAPSHOT is converted to
>  > 2.0.0.incubator-SNAPSHOT.
>
> Why not just keep the names the same? Both end in -SNAPSHOT which 
> seems to satisfy the maven pattern.
>
> On the jackrabbit project 1.4-SNAPSHOT becomes 1.4 at release and a 
> new release is started, this is a nice simple model. However, in your 
> model we have this even/odd flip. The issue, I guess, is that OSGI 
> wants 1.2.3.4.String and not 1.2.3.4-String? What if we always have 
> 1.2.3.4.incubator-SNAPSHOT which gets promoted to 1.2.3.4? Do the 
> semantics of 1.2.3.4.dev-SNAPSHOT state that it is newer than 1.2.3.4 
> since it is a revision of that which gives rise to the need for a 
> revision flip? The problem I see is in speaking of a release, for 
> example, if we are all working on release 2.0 we would be checking out 
> version 1.9.incubator-SNAPSHOT which is a bit confusing no? Is the 
> problem with going from 2.0.incubator-SNAPSHOT to 2.0 a problem with 
> OSGi recognizing the .incubator-SNAPSHOT release as newer than 2.0 or 
> is it purely a human thing? If a human thing I think it is 
> understandable that 2.0 would be the release version whereas 
> the .incubator-SNAPSHOT release is not. Perhaps (assuming that this 
> isn't a problem for the OSGi container) we could use the word .dev-
> SNAPSHOT or something to be more clear.
>
> -paddy
>



Reply via email to