From continuum-dev-return-5144-apmail-maven-continuum-dev-archive=maven.apache.org@maven.apache.org Fri Aug 25 03:42:16 2006 Return-Path: Delivered-To: apmail-maven-continuum-dev-archive@www.apache.org Received: (qmail 81479 invoked from network); 25 Aug 2006 03:42:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 25 Aug 2006 03:42:15 -0000 Received: (qmail 49175 invoked by uid 500); 25 Aug 2006 03:42:15 -0000 Delivered-To: apmail-maven-continuum-dev-archive@maven.apache.org Received: (qmail 49151 invoked by uid 500); 25 Aug 2006 03:42:15 -0000 Mailing-List: contact continuum-dev-help@maven.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: continuum-dev@maven.apache.org Delivered-To: mailing list continuum-dev@maven.apache.org Received: (qmail 49140 invoked by uid 99); 25 Aug 2006 03:42:15 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Aug 2006 20:42:15 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [203.59.1.198] (HELO mail-ihug.icp-qv1-irony4.iinet.net.au) (203.59.1.198) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Aug 2006 20:42:13 -0700 Received: from 203-217-68-125.dyn.iinet.net.au (HELO localhost.localdomain) ([203.217.68.125]) by mail-ihug.icp-qv1-irony4.iinet.net.au with ESMTP; 25 Aug 2006 11:41:51 +0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,166,1154880000"; d="scan'208"; a="866869100:sNHT18285868" Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id E653917C07D for ; Fri, 25 Aug 2006 13:41:32 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1B68711C-5DFC-495A-80F0-BD7F0E1DFCBA@apache.org> Content-Transfer-Encoding: 7bit From: Brett Porter Subject: Re: Release Management for Maven/Continuum Date: Fri, 25 Aug 2006 13:41:32 +1000 To: continuum-dev@maven.apache.org X-Mailer: Apple Mail (2.752.2) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Hi Jan, The release is indeed modifying the pom, tagging the code, and doing a full build and deploy cycle of that code to produce a formal release. I think there is definitely room for another feature which I've always referred to as "build labeling" where you take the existing continuum build, label it as a certain milestone, and then if it passes into the final release stage goes through the build/tag procedure. Some organisations like to do the opposite and tag every build and then its just a matter of picking which is final. So the two would need to cooperate. - Brett On 25/08/2006, at 1:41 AM, Jan Nielsen wrote: > Sorry for jumping in here but I'm not entirely sure I understand the > big-picture process you are describing. Is the only difference > between a > "build" and a "release" the presence of meta-data describing what you > built the release from (and possibly the life-time of that meta-data)? > > If so, one way to implement a "release" is to "tag" everything with > some > release moniker, e.g., "1.0", and then retrieve all these tagged > files, > then build it, and then publish it as your "release 1.0". This has the > obvious benefit of using the SCM system to track release numbers, > but the > drawback that some SCM systems take along time to perform the tag > operation and it requires a two step build procedure, tag-and- > build, which > is not the normal build cycle. For releases spanning multiple > modules this > scheme become complex and very broad. (Is the intent of the > "prepare" step > to perform the "tag" SCM operation?) To recover a past release > build, you > then use the SCM to retrieve the "tagged" files - easy enough. > > Another way is denote a release is to capture the meta-data of > files in > the build, and dependent modules, and then check-in this release > descriptor with the release tag. The drawback to this scheme is > obviously > that the SCM store no longer directly identifies the set of files > with an > explicit release number. But the benefit is that no single "tag" > operation > needs to be done on the entire file set before the build and the > built set > of files is collected after the build operation which can be now be > done > for each build. The release descriptor will then contain the uniquely > identifying information for all files built, collected after the SCM > update operation, and all release descriptors of dependent modules. To > recover a past build, you then use the SCM to get the release > descriptor > and from the release descriptor pull the appropriate POM and files > from > the SCM - this is now a two step procedure, but these two steps > could be > automated. > > As you may have guessed, each of our builds is a "release" which > enables > us after QC completes to define build 12345 as "Release 1.0" (and > once the > release has been defined, you could go back and "tag" each file in the > build with the release moniker if you really want the SCM to hold this > information explicitedly). > > I hope I didn't stir the water. Thoughts? > > -Jan > > > Jan Nielsen * System Architect * SunGard Higher Education * Tel +1 > 801 257 > 4155 * Fax +1 801 485 6606 * jan.nielsen@sungardhe.com * > www.sungardhe.com > * 90 South 400 West, Suite 500, Salt Lake City, UT USA > > CONFIDENTIALITY: This email (including any attachments) may contain > confidential, proprietary and privileged information, and unauthorized > disclosure or use is prohibited. If you received this email in error, > please notify the sender and delete this email from your system. Thank > you. > > > > Brett Porter > 08/23/2006 10:37 PM > Please respond to > continuum-dev@maven.apache.org > > > To > continuum-dev@maven.apache.org > cc > > Subject > Re: Release Management for Maven/Continuum > > > > > > >> The summary page shows only a few of the release parameters. So the >> "Edit" link is there to direct the user to the more detailed >> release configuration page. But since we'll be releasing projects >> one at a time, I guess I can incorporate what you mean into the new >> white-site. > > Just to be clear - if the single project that is released has > modules, there will be multiple entries on this page. > > I think it should be a big long form, though, because it would be > tedious to change individual values project per project when you need > to edit them like that (unless we get all ajax, but that might be a > separate UI initiaive) > >>> >> ok, so this means continuum should remember prepared releases. >> Should there be a separate release working directory for this? >> Because a prepared release may get lost after a scheduled build. > > A prepared release is simply a tag in the SCM, I think (you might > want to double check that that is all release:perform reads back from > the release properties). > > Basically what wuld happen here, after fleshing out the model, is > that it would replace the configuration store in the release plugin > (so you could use Xpp3Reader/Writer to store release.xml instead of > release.properties), and the same thing could be used to store a > release's information in the database, along with the information > here. > > Anyway, maybe I'm going overboard on that, but its something to think > about. > > - Brett >