svn commit: r1585095 - /sling/site/trunk/content/documentation/development/version-policy.mdtext

[ol...@apache.org]

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