svn commit: r1081395 - /aries/site/trunk/content/development/versionpolicy.mdtext

[zo...@apache.org]

Author: zoe
Date: Mon Mar 14 14:32:20 2011
New Revision: 1081395

URL: http://svn.apache.org/viewvc?rev=1081395&view=rev
Log:
formatting version policy

Modified:
    aries/site/trunk/content/development/versionpolicy.mdtext

Modified: aries/site/trunk/content/development/versionpolicy.mdtext
URL: http://svn.apache.org/viewvc/aries/site/trunk/content/development/versionpolicy.mdtext?rev=1081395&r1=1081394&r2=1081395&view=diff
==============================================================================
--- aries/site/trunk/content/development/versionpolicy.mdtext (original)
+++ aries/site/trunk/content/development/versionpolicy.mdtext Mon Mar 14 14:32:20 2011
@@ -1,34 +1,54 @@
-Versioning policy - DRAFT
+# Versioning policy - DRAFT
 
-This projecst aims to implement OSGi semantic versioning as described here: www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf.
+The Aries  project aims to implement OSGi semantic versioning as described [here](www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf).
 
 The implementation of semantic versioning has a number of practical implications for managing a project. These are
 outlined in this section. 
 
-Bundle version.
-OSGi semantic versioning applies to bundles as well as packages. When releaseing a new version of a bundle
+## Bundle versions
+OSGi semantic versioning applies to bundles as well as packages. When releasing a new version of a bundle
 the change in the bundle version should give some indication of nature of the changes to the bundle.
-In Aries the bundle version is always the same as version of the Maven artifact that relates to the bundle. 
-During development teh Maven artifact version may be either:
+In Aries the bundle version is the same as version of the Maven artifact version. 
+During development, in trunk, the Maven artifact version may be:
 
-  * x.y.z Where x.y.z is the most recent release of the bundle
-  * x.y.(z+1)-SNAPSHOT Indicating that the bundle has changed since it was last released.
+  * either x.y.z Where x.y.z is the most recent release of the bundle
+  * or x.y.(z+1)-SNAPSHOT Indicating that the bundle has changed since it was last released.
 
-Immediately after a release the Maven version is  set the same as the release. Bundles which depend
+Immediately after a release the Maven version is set the same as the release. Bundles which depend
 on the bundle will pick up the released version. When a developer first makes a change to the bundle the version
 is changed to be a SNAPSHOT version, indicating to a release manager that the bundle is a candidate for release.
 
 At release time the release version of the bundle must be assigned by the release manager after reviewing
-the changes since the last release.
+the changes to the bundle's package versions since the last release.
 
 
-Package versions
+## Package versions
 
-Exported packages
-Versions specified in packageinfo files with teh source code.
-The location of pacgageinfo is configured in build resounces in the default-parent pom. If your pom has a build resources section it replaces what is inherited from teh default-parent, so you may need to reproduce the section which specifies where packageinf can be found.
+### Exported packages
+Versions are usually specified in packageinfo files with the source code. The default-parent pom is 
+configures (in the build resources section) to expect packageinfo files. If your pom has a build
+resources section it replaces what is inherited from the default-parent, so you may need to reproduce 
+the section which specifies where packageinfo can be found.
 
-Imports
-The bnd defualt verion range policy for imports is teh consumer policy (==, +), you may need to override this if you want to be more prescriptove about secific aries imports.
+Developers **must** increment the versions in packageinfo files in strict accordance with OSGi
+semantic versioning when they make changes to a package. The version should relate to the most
+recent release of the package and not to the version found in trunk. For example:
+
+ * Scenario 1, making changes to a package with released version a.b.c
+  * Developer A fixes a bug in the package and increments it's version to a.b.c+1
+  * Developer B fixes another bug in the package but leaves the version at a.b.c+1 
+
+ * Scenario 2, making changes to a package with released version a.b.c
+  * Developer A fixes a bug in the package and increments it's version to a.b.c+1
+  * Developer B makes an API breaking change and increases the package version to (a+1).0.0
+ 
+
+
+
+## Importing packages
+The bnd default version range policy for imports is the consumer policy (==, +), you may need to 
+override this if you want to be more prescriptive about specific Aries imports.
+The policy can be set by using the Maven property <aries.osgi.version.policy>, see the default-parent
+pom for an example.