Version 14

    JBoss Eclipse IDE Release Process

    -


    Prereqs for using this build

    1. Install infozip

    2. Have write access to download.jboss.org/jbosside

    3. ANT 1.6.5 is required.  Set your ant home to the appropriate location.

    4. This build requires SCP ability to download.jboss.com.   All QA users have been setup, by default the build script uses the correct login. The private key which is accessed by the build must be in openssh format.

    5. Ensure that the latest version of jsch.jar is installed in your ANT_HOME/lib directory

    -


    1. Each component's repository must be tagged for release. Generally, here are the current tag naming conventions we have for each component:

      1. JBossIDE Core: IDE_CORE_RELEASENAME

      2. JBossAOP Developer: IDE_AOP_DEVELOPER_RELEASENAME

      3. EJB3 Tools: IDE_EJB3_TOOLS_RELEASENAME

      4. Hibernate Tools: TOOLS_RELEASENAME

      5. 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

      1. cvs co jbosside/releng/org.jboss.ide.eclipse.releng

    4. From directory releng/org.jboss.ide.eclipse.releng execute the following:

      1. ant -f customizeBuild.xml

    5. This will launch a gui

      1. Create temp dirs for the appropriate locations

      2. You may need to execute 'ant -f customizeBuild.xml customize' to create a build.properties file.

    6. Create a tags file, RELEASENAME.tag in the folder builders/product/versionTags

      1. You can see an example tags file from the 1.5.1.GA release here

      2. You will need to know the sub version for each component. 

      3. The integration build is ran using this command in the builders directory of JBossIDE releng:

        1. cd releng/org.jboss.ide.releng/builders

        2. ./build-integration.sh product -tags Tagsfile

        3. See more info at the [JBossIDE Releng System

    Docs|http://docs.jboss.com/jbosside/releng/user/build/en/html/index.html]

        1. example:  ./build-integration.sh product -tags product/versionTags/1.5.2.GA.tags

      1. You will need to expand the eclipse-SDK which is downloaded into a an additional dir which you specify

      2. Also, may need to modify global.properties updating as follows:

        1. pdescriptdir=${clean.eclipse.home}/plugins/org.eclipse.pde.build_3.1.2/scripts

      3. 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

    1. 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).

      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. Once we receive the "thumbs-up" from all component leads, it's time to make a release build.

    2. At this point, the tags file should be committed to Releng cvs.

    3. If the release is "stable" (i.e. non beta/RC/etc) then you will run this command in the builders directory:

      1. ./build-release.sh product stable RELEASENAME

    4. Otherwise if the release is "development" (beta/RC/etc) then you will run this command:

      1. ./build-release.sh product development RELEASENAME

    5. The component leads are given a final chance to go over the release build before it will be published.

      1. If there are any complaints, restart the process with the integration build

      2. If all component leads give "thumbs-up", then it's time to upload and announce.

    6. 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)

    7. While the files are uploading, I create the release in Sourceforge, and call it JBossIDE RELEASENAME.

    8. I collect and enter the Changelog/ReleaseNotes from JIRA and various notes given to me from component leads.

    9. 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")

    10. Now the only thing left to do is update the product download page and announce on the forums.

    11. The "old" newest release is removed and replaced by the "new" newest release, including links to Sourceforge etc.

    12. Release announcement is made on the JBossIDE User Forums and  Developer Forums. You can find an example announcement here

    13. After the announcement is made, all of the people watching on Sourceforge are notified.