2 Replies Latest reply on Mar 27, 2007 1:12 PM by Scott Stark

    New Release Process

    Paul Gier Master

      Here is an outline of what we are thinking as far as a release process for jboss projects:

      1) Project lead notifies all developers that no more commits should happen until the release is over.

      2) Project lead runs mvn release:prepare -DdryRun=true. This verifies that all the build settings required for a release are available. The release version, and the new trunk version should be communicated to release engineering.

      3) Release engineering team runs mvn release:prepare. This creates the tag in svn, and defines the version to be released.

      4) Release engineering team runs mvn release:perform. This generates all artifacts from the new tag and deploys them to a staging server.

      5) QA uses the artifacts on the staging server to verify that everything works correctly

      1. If QA does not find any issues, go to step 6.

      2.If QA does find issues with the build, the project goes back to development. Once the issues are resolved, the tag is deleted and the process goes back to step 2.

      6)Release engineering promotes the files to production servers.

        • 1. Re: New Release Process
          Paul Gier Master

          Some questions for discussion:

          Instead of creating a tag directly off the trunk, maybe we should first create a branch for the release and increment the trunk to the next version? Then the tag would be created from the branch, and if problems are found in the tag, the tag is deleted, and the bugs are fixed in the branch. The maven release plugin is not currently set up to do branches, but this is something that could probably be added pretty easily.

          Instead of having QA test the actual release, maybe they can test the release candidate version, and if everything is fine, then we just rename the release candidate and do some verification that the bits are the same.

          • 2. Re: New Release Process
            Scott Stark Master

            For any reasonably stable project I already expect there to be a branch. The issue with incrementing either the branch or trunk to the next version exists for either strategy as both end up with a codebase that does not match the tag as soon as another change is made. The http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html docs say that existing poms are updated though:

            Bump the version in the POMs to a new value y-SNAPSHOT (these values will also be prompted for)

            If that is the case whether or not a branch is used is just a function of the project maturity/policy. If there is not already a branch its not helping much to create one.