Hi all, After talking with Jason I have started on phase 1 of this venture. Phase 1 is as follows:
1. Create a model for Maven to use for the release descriptor 2. Integrate the model into the Maven release plugin I know...it seems too simple but that should be phase 1. What this will do is allow Maven to use a Java object, which can be persisted to a file like XML, to store the model. Why is this important? Once we want to have Continuum be able to perform the release it is as simple as sending the release descriptor object to Continuum to do the work and return a status. Phase 2 will start with Continuum facing things which will get Continuum capable of performing the release and returning a release status object. This phase will also be used to update the web interface to be able to perform releases based on the guidelines Brett and Jason have discussed in this email. Phase 3 will be to modify the Maven release plugin model to allow for Continuum bits to be stored in the model and used to delegate the release process to Maven. This process will also involve having Maven handle the release status object returned. How does this sound? It is pretty high level and does not discuss or outline any of the lower level details. Take care, Jeremy P.S. - This email is the result of Jason and I talking so if I butchered what was discussed, please let me know Jason. On 8/24/06, Jan Nielsen <[EMAIL PROTECTED]> 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 * [EMAIL PROTECTED] * 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 <[EMAIL PROTECTED]> 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
