[jboss-user] [JBoss Tools] Document updated/added: "DevStudioReleaseProcess"

[Max Andersen]

User development,

The document "DevStudioReleaseProcess", was updated Jan 20, 2010
by Max Andersen.

To view the document, visit:
http://community.jboss.org/docs/DOC-9570#cf

Document:
--------------------------------------------------------------
h3. JBoss Developer Studio and JBossTools Release Process
-
----
Prereqs for using this build
1. Install infozip
2. Have write access to download.jboss.org/jbosstools
3. Have file release permissions on sourceforge.net
 
-
----
1. Each component's repository must be tagged for release. Generally, we do a wide-sweeping tag for the entire jbosstools repository, while a few components (namely jBPM) have their own repositories and tags. You can easily tag a release by using the "make_tags.sh" script in releng's util directory.

TAG=jbosstools-2.1.2.GA BRANCH=branches/jbosstools-2.1.x ./make_tags.sh

 
0.1. 
0.2. JBossIDE Core: IDE_CORE_RELEASENAME
0.3. JBossAOP Developer: IDE_AOP_DEVELOPER_RELEASENAME
0.4. EJB3 Tools: IDE_EJB3_TOOLS_RELEASENAME
0.5. Hibernate Tools: TOOLS_RELEASENAME
0.6. jBPM Designer: jbpm_gpd_releasename
2. After tagging is complete, an integration build is made on those tags.
3. Checkout the build system for JBossIDE
3.1. cvs co jbosside/releng/org.jboss.ide.eclipse.releng
5. From directory releng/org.jboss.ide.eclipse.releng execute the following:
5.1. ant -f customizeBuild.xml
7. This will launch a gui
7.1. Create temp dirs for the appropriate locations
7.2. You may need to execute 'ant -f customizeBuild.xml customize' to create a build.properties file.
9. Create a tags file, RELEASENAME.tag in the folder builders/product/versionTags
9.1.  You can see an example tags file from the 1.5.1.GA release http://fisheye.jboss.com/viewrep/JBoss/jbosside/releng/org.jboss.ide.eclipse.releng/builders/product/versionTags/1.5.1.GA.tags?r=1.1
9.2. You will need to know the sub version for each component.  
9.3. The integration build is ran using this command in the builders directory of JBossIDE releng:
9.3.1. cd releng/org.jboss.ide.releng/builders
9.3.2. ./build-integration.sh product -tags tagsfile 
9.3.3. See more info at the [JBossIDE Releng System 
Docs|http://docs.jboss.com/jbosside/releng/user/build/en/html/index.html]
0.0.1. example:  ./build-integration.sh product -tags product/versionTags/1.5.2.GA.tags
0.2. You will need to expand the eclipse-SDK which is downloaded into a an additional dir which you specify
0.3. Also, may need to modify global.properties updating as follows:
0.3.1. pdescriptdir=${clean.eclipse.home}/plugins/org.eclipse.pde.build_3.1.2/scripts 
0.5. If the integration build breaks on compilation, the component lead responsible is notified and they re-tag their repository. We then re-initiate the integration build
2. Once the integration build is complete, each component lead is notified of the build and is responsible for doing any tests to their satisfaction on that build. (Note that this is usually outside the scope of unit tests).
2.1. If there are any fatal bugs / problems in the integration build, we give the responsible component leader time to fix those bugs, and re-start the process.
2.2. Once we receive the "thumbs-up" from all component leads, it's time to make a release build.
4. At this point, the tags file should be committed to Releng cvs.
5. If the release is "stable" (i.e. non beta/RC/etc) then you will run this command in the builders directory:
5.1. ./build-release.sh product stable RELEASENAME
7. Otherwise if the release is "development" (beta/RC/etc) then you will run this command:
7.1. ./build-release.sh product development RELEASENAME
9. The component leads are given a final chance to go over the release build before it will be published.
9.1. If there are any complaints, restart the process with the integration build
9.2. If all component leads give "thumbs-up", then it's time to upload and announce.
11. I first start by uploading all of the release files to sourceforge. Depending on the connection this can easily take a few hours. I have an ant script that automates this process for me that I've attached to this wiki. It's syntax is ./sf_upload.sh RELEASENAME (it probably needs to be changed to work on other systems)
12. While the files are uploading, I create the release in Sourceforge, and call it JBossIDE RELEASENAME.
13. I collect and enter the Changelog/ReleaseNotes from JIRA and various notes given to me from component leads.
14. After the files are done uploading, I add all of the appropriate files into the release, and describe them correctly using SF's interface (MD5 files get "Other", zips get ".zip", .tar.gz gets ".gz")
15. Now the only thing left to do is update the product download page and announce on the forums. 
16. The "old" newest release is removed and replaced by the "new" newest release, including links to Sourceforge etc.
17. Release announcement is made on the JBossIDE http://jboss.com/index.html?module=bb&op=viewforum&f=201 and  http://jboss.com/index.html?module=bb&op=viewforum&f=162. You can find an example announcement http://jboss.com/index.html?module=bb&op=viewtopic&t=78678
18. After the announcement is made, all of the people watching on Sourceforge are notified.
 

--------------------------------------------------------------