Return-Path: Delivered-To: apmail-aries-commits-archive@www.apache.org Received: (qmail 68925 invoked from network); 9 Feb 2011 16:53:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 9 Feb 2011 16:53:36 -0000 Received: (qmail 68205 invoked by uid 500); 9 Feb 2011 16:53:36 -0000 Delivered-To: apmail-aries-commits-archive@aries.apache.org Received: (qmail 68133 invoked by uid 500); 9 Feb 2011 16:53:34 -0000 Mailing-List: contact commits-help@aries.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@aries.apache.org Delivered-To: mailing list commits@aries.apache.org Received: (qmail 68112 invoked by uid 99); 9 Feb 2011 16:53:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Feb 2011 16:53:34 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Feb 2011 16:53:33 +0000 Received: by eris.apache.org (Postfix, from userid 65534) id C1D9823889EB; Wed, 9 Feb 2011 16:53:13 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r785095 - /websites/staging/aries/trunk/content/development/ReleaseProcessRequirements.html Date: Wed, 09 Feb 2011 16:53:13 -0000 To: commits@aries.apache.org From: buildbot@apache.org X-Mailer: svnmailer-1.0.8 Message-Id: <20110209165313.C1D9823889EB@eris.apache.org> Author: buildbot Date: Wed Feb 9 16:53:13 2011 New Revision: 785095 Log: Staging update by buildbot Modified: websites/staging/aries/trunk/content/development/ReleaseProcessRequirements.html Modified: websites/staging/aries/trunk/content/development/ReleaseProcessRequirements.html ============================================================================== --- websites/staging/aries/trunk/content/development/ReleaseProcessRequirements.html (original) +++ websites/staging/aries/trunk/content/development/ReleaseProcessRequirements.html Wed Feb 9 16:53:13 2011 @@ -258,17 +258,20 @@ current process did not use semantic ver

Conceptually very simple of consumers. For example, if as a consumer I pick up something called Blueprint version 0.4 I know that I will need to get Util version 0.4 to go with it.
A relatively simple release process, one JIRA component, one set of release notes.i
A relatively simple release process, one JIRA component, one set of release notes.
We can release a set of samples at the same version with some guarentee that the samples all work with the release.

Disadvantages of releasing everything at once

Not using of OSGi semantic versioning of bundles.i After every we release we bump the major versions of all bundles in trunk.
Not using of OSGi semantic versioning of bundles. After every we release we bump the major versions of all bundles in trunk.

Package versions are managed separately and the Maven bundle plugin will ensure packges are imported in the correct range based of - the projects dependencies. Implementors need to use "provide:=true" to get the correct range. Package export version should be maintained either using package.info or in the pom.

Package versions are managed separately (correctly) and the Maven bundle plugin will ensure packges are imported in the correct range based of + the projects dependencies. Implementers need to use "provide:=true" to get the correct range. Package export version should be maintained +either using package.info or in the pom.xml.

Releasing by module

Our ideal for a release process would involve to release by module, one might visualise the process like this:

Our ideal for a release process would involve to release by module, this is +really just an evolution of the process that we already use but it would involve +using semantic versioning of bundles. One might visualise the process like this:

rel

In this case, we have a module version (independent of the version of its sub-modules) and a set of sub-modules which may each be indepndently versioned.