continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: Release Management for Maven/Continuum
Date Fri, 25 Aug 2006 03:41:32 GMT
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 <brett@apache.org>
> 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
>

Mime
View raw message