Skip to end of metadata
Go to start of metadata

Releasing FlexJS with Maven involves quite a number of steps, the default maven-release-plugin can be used to automate most of them.

Step-by-step guide

The general release procedure with Maven is:

  1. On the dev mailing-list start the "[LAST CALL]" discussion and follow it till all features planned for the release are implemented
  2. As first step of the release process, use the maven-release-plugin to initiate the release branch.
    mvn release:branch -DbranchName=release/{release-version}

    This branches the current branch and names that branch "release/0.8.0" for example. The version of the original branch is then automatically incremented to the next version. So if the "develop" branch was in version "0.8.0-SNAPSHOT", the code in the release branch will still be in "0.8.0-SNAPSHOT" and the develop branch will be in "0.9.0-SNAPSHOT".
  3. After the release branch being cut, the team has time to test and fix any bugs found on the release branch.
  4. At the time all bugs are fixed, that needed fixing and the team reaches consensus on creating a release candidate, the RM prepares a release:
    mvn release:prepare -Dautoversionsubmodules=true

    This will do a lot of things (The "autoversionsubmodules" parameter ensured that all modules are released with the same version information):
    1. Check if any external SNAPSHOT versions are referenced (You can't release when still referencing any external SNAPSHOT versions)
    2. Change the version of all modules to the release version (usually by simply cutting off the "-SNAPSHOT" suffix)
    3. Run a build with all tests on this updated version
    4. If the build was successful, automatically tag the code version
    5. Update the versions of all modules to the next development version (In a release branch this is usually a bugfix version, so if we were releasing 0.8.0-SNAPSHOT, the release version would be 0.8.0 and the next develop version would be 0.8.1-SNAPSHOT
    6. Commit these changes 
    7. Push the changes
  5. Now in general everyone could checkout the tag and check the RC, but usually the last step is immediately followed by the prepare step:
    mvn release:perform

    This will do the following steps:

    1. checkout the just prepared release into the target directory inside a "checkout" directory.

    2. run a maven build including all tests with activated "apache-release" profile (This will make the build produce and sign all artifacts and additionally create and sign source and javadoc artifacts)
    3. deploy the artifacts to a so-called "staging repository" in the ASF Nexus (This is a dynamically created maven repository only containing the artifacts of the current build)
  6. The RM logs in to Nexus and closes the staging repository (in case of the FlexJS project we will be doing 3 releases into the same repo, so it's better to close it after finishing the release of the framework module)
  7. Nexus automatically does some pre-release checks: 
    1. All artifacts are accompanied by source artifacts
    2. All checksums of artifacts are correct
    3. All signatures are correctly signed by the key of someone listed as committer in the ASF
  8. The RM posts a link to the staging repo on the list and starts the "[VOTE]" and "[DISCUSS]" threads
  9. If the vote passes the RM logs on to Nexus, selects the staging repository and clicks on the "Release" button.

Now if the vote doesn't pass, the release process needs to be reverted. This is done by the following steps:

  1. The RM logs on to Nexus, selects the staging repo and clicks on the "Drop" button (This simply deletes the repo with all its content)
  2. The RM uses the maven version plugin to reset the version of the release branch to "0.8.0-SNAPSHOT" (Or the next RC simply gets the next bugfix version... that's up to the project)
    mvn versions:set -DnewVersion=0.8.0-SNAPSHOT

    This simply updates the versions of all artifacts to the "newVersion" version. So now the repo is back to the version before cutting the release candidate.
  3. Now we need to manually delete the tag created by the last release attempt and make sure to push the tag-deletion to the asf git repo.
  4. Now all should be set to fix the issues found in the RC and to start a new RC as soon as that's done.

Ok so that was the general process of releasing and it can be directly applied to the FlexJS Compiler artifact. The Typedefs and Framework need one additional step.

  1. After the release candidate for compiler is created, the "flexjs.compiler.version" property in the Typedefs and Framework root poms need to be adjusted to the release version (This is done manually) (if this is not done, the release prepare step will fail because we are referencing unreleased versions)
  2. The Framework module needs to be updated with the "flexjs.typedefs.version" after the RC of Typedefs is created.