continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Nielsen <>
Subject Re: Release Management for Maven/Continuum
Date Thu, 24 Aug 2006 15:41:25 GMT
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 

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 Nielsen * System Architect * SunGard Higher Education * Tel +1 801 257 
4155 * Fax +1 801 485 6606 * * 
* 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 

Brett Porter <> 
08/23/2006 10:37 PM
Please respond to


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, 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 

- Brett

View raw message