Return-Path: Delivered-To: apmail-aries-commits-archive@www.apache.org Received: (qmail 97915 invoked from network); 9 Feb 2011 14:53:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 9 Feb 2011 14:53:38 -0000 Received: (qmail 58841 invoked by uid 500); 9 Feb 2011 14:53:38 -0000 Delivered-To: apmail-aries-commits-archive@aries.apache.org Received: (qmail 58760 invoked by uid 500); 9 Feb 2011 14:53:35 -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 58749 invoked by uid 99); 9 Feb 2011 14:53:34 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Feb 2011 14: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 14:53:32 +0000 Received: by eris.apache.org (Postfix, from userid 65534) id 508C92388903; Wed, 9 Feb 2011 14:53:11 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r1068919 - /aries/site/trunk/content/development/ReleaseProcessRequirements.mdtext Date: Wed, 09 Feb 2011 14:53:11 -0000 To: commits@aries.apache.org From: zoe@apache.org X-Mailer: svnmailer-1.0.8 Message-Id: <20110209145311.508C92388903@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Author: zoe Date: Wed Feb 9 14:53:10 2011 New Revision: 1068919 URL: http://svn.apache.org/viewvc?rev=1068919&view=rev Log: spelling and english Modified: aries/site/trunk/content/development/ReleaseProcessRequirements.mdtext Modified: aries/site/trunk/content/development/ReleaseProcessRequirements.mdtext URL: http://svn.apache.org/viewvc/aries/site/trunk/content/development/ReleaseProcessRequirements.mdtext?rev=1068919&r1=1068918&r2=1068919&view=diff ============================================================================== --- aries/site/trunk/content/development/ReleaseProcessRequirements.mdtext (original) +++ aries/site/trunk/content/development/ReleaseProcessRequirements.mdtext Wed Feb 9 14:53:10 2011 @@ -23,11 +23,13 @@ current process did not use semantic ver ![rel](release_by_module.png)

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. + ## Advantages of release by module - 1. Releaseing a coherent set of bundles that have been built and run together - 1. Releaseing a buildable set of source for all constituent bundles in one zip file + 1. Releasing a coherent set of bundles that have been built and run together + 1. Releasing a buildable set of source for all constituent bundles in one zip file 1. A more consumable unit than a set of single bundles - easier for Aries consumers. A smaller number of discrete downloads. -## Disadvantages of teh release by module process + +## Disadvantages of the release by module process 1. We would want to release a whole module at once, this would mean re-releasing bundles at the same level (and with the same content) as a previous release. This is not a major issue 1. Developer would need to be careful to version submodules poms independently from the parent/reactor pom. Again, @@ -38,11 +40,11 @@ and maintain our own alternative, to all 1. It's not all clear what the strategy for branching would be. For example, consider the following scenario: ![rel](branches_and_modules.png)

The bundles in trunk should be versioned differently from the versions in branch. This really mandates a bump in the major version. -The consequence of not bumping the major version and using the versioning tool to compare versions in trunk (for the next release from trunk) -and using the versioning tool to create bug fix versios from the branch has the potential to lead to the situation in which bundles with the +

The consequence of not bumping the major version and using the versioning tool to compare versions in trunk (for the next release from trunk) +and using the versioning tool to create bug fix versions from the branch has the potential to lead to the situation in which bundles with the same version number have different content. -For example, as time goes on you create another release (version 6) of the proxy module, the version compare tool tells you that proxy-impl -should be released at version 0.4.2, so that is released in a module release at version 6. But now, somone who wants a fix to proxy-impl in 0.4.1 which we would want to do -from the branch, would also get a proxy-impl bundle at version 0.4.2 with different content. +For example, as time goes on another release (version 6) of the proxy module is created, the version compare tool dictates that proxy-impl +should be released at version 0.4.2. But now, someone who wants a fix to proxy-impl in 0.4.1 (in proxy module version 5) which would be provided +from the branch, would also get a proxy-impl bundle at version 0.4.2 with different content. This is a situation which must be avoided.