sling-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From o...@apache.org
Subject svn commit: r1585095 - /sling/site/trunk/content/documentation/development/version-policy.mdtext
Date Sat, 05 Apr 2014 14:02:59 GMT
Author: olli
Date: Sat Apr  5 14:02:59 2014
New Revision: 1585095

URL: http://svn.apache.org/r1585095
Log:
fix some glitches

Modified:
    sling/site/trunk/content/documentation/development/version-policy.mdtext

Modified: sling/site/trunk/content/documentation/development/version-policy.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/documentation/development/version-policy.mdtext?rev=1585095&r1=1585094&r2=1585095&view=diff
==============================================================================
--- sling/site/trunk/content/documentation/development/version-policy.mdtext (original)
+++ sling/site/trunk/content/documentation/development/version-policy.mdtext Sat Apr  5 14:02:59
2014
@@ -17,7 +17,7 @@ In comments to [SLING-1176](https://issu
 
 I agree, that this is a problem. So let me reasonate on this a bit ;-)
 
-As a reference you might want to read [my blog post on version numbers](http://blog.meschberger.ch/2009/10/on-version-numbers.html)
and also what the [Eclipse guys have to say|http://wiki.eclipse.org/index.php/Version_Numbering]
(great read, btw). The OSGi Alliance has come up with a good definition for [Semantic Versioning|http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf]
to which the definitions described below perfectly match.
+As a reference you might want to read [my blog post on version numbers](http://blog.meschberger.ch/2009/10/on-version-numbers.html)
and also what the [Eclipse guys have to say](http://wiki.eclipse.org/index.php/Version_Numbering)
(great read, btw). The OSGi Alliance has come up with a good definition for [Semantic Versioning](http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf)
to which the definitions described below perfectly match.
 
 For Sling we have three kinds of version numbers:
 
@@ -27,7 +27,7 @@ For Sling we have three kinds of version
 
 ### Big Sling Releases
 
-For *Big Sling releases* we already have an ample solution in that we just use a single number
increased from release to release. Just remember that a *Big Sling release* is a convenience
release of existing released Sling bundles.
+For *Big Sling Releases* we already have an ample solution in that we just use a single number
increased from release to release. Just remember that a *Big Sling Release* is a convenience
release of existing released Sling bundles.
 
 ### Sling Bundles
 
@@ -41,9 +41,9 @@ For *Package Exports* the situation is m
 * Explicitly in the `<Export-Package>` element of the Maven Bundle Plugin configuration
 * By reference to the bundle version number using the `${pom.version}` variable.
 
-Upto now, we mostly used the `${pom.version}` notation linking the exported package version
to the bundle version. Over time this mechanism leads to a number of problems:
+Up to now, we mostly used the `${pom.version}` notation linking the exported package version
to the bundle version. Over time this mechanism leads to a number of problems:
 
-* For bundles with more than one package exported, the exported packages will evolve independently.
As a consequence their versionin should also evolve independently. An example of such a bundle
is the Sling API bundle of course.
+* For bundles with more than one package exported, the exported packages will evolve independently.
As a consequence their versioning should also evolve independently. An example of such a bundle
is the Sling API bundle of course.
 * Linking the package export version number to the bundle version number confuses the actual
semantics of both version numbers. The package export version number only indicates the version
of the actual package while the bundle version number indicates a development state of the
overall bundle. This will generally not be the same.
 * The version of the exported package is increased on each bundle release, even though nothing
may have changed on the export. In such a situation the version of the export should stay
the same.
 
@@ -85,14 +85,14 @@ See [BND Versioning](http://www.aqute.bi
 
 ## Version Number Syntax
 
-As a small reminder, this is how a version number is constructed:  In OSGi version numbers
are composed of four (4) segments: 3 integers and a string named major.minor.micro.qualifier.
+As a small reminder, this is how a version number is constructed:  In OSGi version numbers
are composed of four (4) segments: three integers and one string named _major_._minor_._micro_._qualifier_.
 
 Each segment captures a different intent:
 
 * the major segment indicates breakage in the API
 * the minor segment indicates *externally visible* changes
 * the micro segment indicates bug fixes
-* the qualifier segment is not generally used but may be used to convey more information
about a particular build, such as a build time or an SVN revision number.
+* the qualifier segment is not generally used but may be used to convey more information
about a particular build, such as a build time or a SVN revision number.
 
 
 ## Evolution of Exported Package Versions
@@ -197,7 +197,7 @@ This allows for the implementation to wo
 
 ### Future
 
-Recent versions of the BND library support automatic differntiation between use and implementation
of API and to set the import version ranges accordingly. See [BND Versioning](http://www.aqute.biz/Bnd/Versioning)
for details.
+Recent versions of the BND library support automatic differentiation between _use_ and _implementation_
of API and to set the import version ranges accordingly. See [BND Versioning](http://www.aqute.biz/Bnd/Versioning)
for details.
 
 ## References
 



Mime
View raw message