Prerequisites

Pre-release

 

The rest of this document describes the actions the RM must take to prepare the SDK for the various release steps:

Preparing Sources

  • Ensure the LICENSE and NOTICE files are current. Check that the years in the copyright statement in the NOTICE file are correct.
  • Update the README. Make sure the list of dependencies and their licenses is still accurate. Update the version number.
  • Update RELEASE_NOTES. Include list of bugs that were fixed in this release.
  • If it hasn't been done already, make sure the version information has been updated in build.properties, modules/compiler/src/java/flex2/tools/VersionInfo.java, modules/compiler/src/java/flex2/compiler/common/MxmlConfiguration.java, and frameworks/projects/framework/src/mx/core/FlexVersion.as. The script build/set-version.xml will do most of this for you and remind you to edit MxmlConfiguration.java and FlexVersion.as by hand. Usage (from SDK root): "ant -f ./build/set-version.xml -Dmajor=4 -Dminor=15". Updating build.properties will update the name of the packages to apache-flex-sdk-${release.version}-src and -bin. As part of the release build, the frameworks/**/Version.as files will be updated with the release version and build number.
  • It is highly recommended that you do a release build and Mustella run in the develop branch and any fix any known build process issues before branching for the release.

Creating a Release Branch

  • Ensure your local 'develop' branch is up-to-date
    Make sure that the path that the source is checked out to does not contain spaces.

  • Create a new remote 'release' branch

    git checkout -b releaseX.Y.Z
git push -u origin releaseX.Y.Z 

    Another RM originally suggested using the below command instead, but that caused the develop branch to track the release branch and made merging more confusing later

    git push -u origin develop:releaseX.Y.Z

  • Create a new directory, change to it and check out the develop branch.

    git clone https://git-wip-us.apache.org/repos/asf/flex-sdk.git .

  • Checkout the new release branch with:

    git checkout releaseX.Y.Z

     

    Most of the rest of these steps have been placed in an Ant script so you can run one script and not have to keep referring back to these steps and worry about typing the commands correctly.  See Release Manager and Release Voter Ant Scripts for details on the scripts

     

  • Tag the release

    git tag -a apache-flex-sdk-X.Y.ZRCx -m 'Apache Flex X.Y.Z RCx'
git push --tags

You may also want to use the make_release_branch.sh script:

make_release_branch.sh X.Y.Z

Building the Release

  • Build the source and binary packages.

    cd build
./build_release.sh

    The packages can be found in the out subdirectory.

Every time you make a release candidate make sure that there have been no changes to the tagged set of files in particular config files.

This could indicate an issue:

git status

# On branch release4.11.0
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   ide/flashbuilder/config/air-config.xml
#	modified:   ide/flashbuilder/config/airmobile-config.xml
  • Check the RAT log in rat.log to make sure no binaries or unlicensed files where inadvertently introduced into the source kit.
  • Other ant targets you may want to become familiar with are source-release, source-package, binary-release, binary-package and rat-check. These are useful if you modify the files in the kit and you want to short circuit some of the build process to test your changes.

Verifying the Kits

  • Verify the asc and md5 signatures for both kits then unzip both the source and binary kits.
    You may also want to use the check_sigs.sh script:

    check_sigs.sh X.Y.Z RC
  • Verify that the name, version and build number are correct in flex-sdk-description.xml.

  • Verify that the source files in the zip kit have Windows line endings and the source files in the OSX kit has Unix line endings.

    cd apache-flex-sdk-X.Y.Z-src
ant main checkintests

  • Verify that the components in the binary kit can be built.

    cd apache-flex-sdk-X.Y.Z-bin/frameworks
ant
  • Double-check the spelling and grammar in README, LICENSE and RELEASE_NOTES files.
  • Verify that the SDK can be used with Adobe Flash Builder version 4.6 and 4.7. See ide/flashbuilder/README_integration_with_Adobe_FlashBuilder.txt for the list of checks that Adobe Flash Builder performs on the Apache SDK to ensure compatibility of the SDK with Flash Builder. You can use ide/flashbuilder/makeApacheFlexForFlashBuilder.sh in either the binary kit or the source kit build with "ant main frameworks-rsls".

Testing the Release

The entire mustella test suite should be run.

Signing the Release

The build script will prompt for the password to your KEY and sign the release.

To manually sign the release copy the Apache script 'sign_and_hash.sh' from the build directory to the out directory.

cd build
cp ./sign_and_hash.sh ../out
cd ../out
./sign_and_hash.sh

Staging the Release

The release manager should stage the release candidate (RC) by placing it in the sdk directory of the 'dist.apache.org/repos/dist/dev/flex/' SVN repo (1).

If we continue to follow the current convention the directory structure would be.

   sdk/
      rc x/
         README
         RELEASE_NOTES
         source packages and signatures
         binaries/
            binary packages and signatures
         doc/
            asdoc package

The README page will not be visible so rename it READme.

When approved by a VOTE, the RC directory contents should be moved to the 'dist.apache.org/repos/dist/release/flex/[flex.version]/' repo (1).

1: http://www.apache.org/dev/release.html#upload-ci

You may also want to use the deploy_release_candidate.sh script:

deploy_release_candidate.sh X.Y.Z RC

The Vote

Start the vote on the flex-dev mailing list; encourage each contributor to take the following steps before voting:

  1. download the source code package.
  2. verify the the signature on the package
  3. compile the source code
  4. test the resulting executables on their own platform.
  5. Optional: download the binary package, build the framework, and ensure the binary distribution passes basic tests.

The RM may call the result of the vote no sooner than 72 hrs. after it was started. Since a release vote is 'Majority Approval', a release is approved if it gets at least 3 binding +1 votes and more binding +1 than -1 votes. Binding votes are cast by PMC members. For a complete list of PMC members, see http://people.apache.org/committers-by-project.html#flex-pmc.

If the vote is successful, post the result to the dev@ list (include the number of binding and non-binding votes); promote and distribute the release. See Promoting the Release.

If the vote is unsuccessful, fix the issues and restart the process. See Canceling the Release.

Canceling the Release

If the vote fails, or you decide to redo the release:

  • Remove the release candidate from the staging area.
  • Make required changes

  • Tag the new release candidate

    git tag -a apache-flex-sdk-X.Y.ZRCx -m 'Apache Flex X.Y.Z RCx'
git push --tags

    You may also want to use the tag_release_candidate.sh script:

    tag_release_candidate.sh X.Y.Z RC
  • Continue with creating a new release. See Building the Release.

Tagging the Repository

Tag the release in git, the tag name and commit message with the relevant release information. You must ensure the source in the package matches the tag.

git tag -a apache-flex-sdk-X.Y.Z -m 'Apache Flex X.Y.Z'
git push --tags

You may also want to use the tag_release.sh script:

tag_release.sh X.Y.Z

Merging back into develop and master

If the release produces Maven artifacts, it is best to merge to master first, then update Maven versions, then merge to the develop branch.

  • Check out the develop branch

    git checkout master
git pull

  • Test merging the release branch into the master branch

    git merge --no-commit --no-ff releaseX.Y.Z

  • If no issues merge the release branch into the master branch

    git merge --no-ff releaseX.Y.Z

  • Check merged changes back into the remote master branch

    git push

  • Change the maven version and delete the backup files

    mvn versions:set -DnewVersion=X.Y.(Z+1)-SNAPSHOT
find . -name *.versionsBackup -delete

  • Commit it

    git add .
git commit -m "update maven versions to next version" 

To merge the released code back into the master branch, repeat the above steps using 'develop' instead of 'master'.  Also update the build.properties that have the latest version number in most of our repos, and update version numbers the sdk-installer-config-4.0.xml file that the Installer uses for the nightly builds.

Promoting the Release

  • Publish the release. Use svn mover or copy to copy the release to https://dist.apache.org/repos/dist/release/flex.
  • Only remove the previous version once the mirrors have caught up (24 hours) and after the installer is updated to use the new release.
  • Update JIRA. Go to the Admin section on the Flex JIRA and mark Flex X.Y.Z as released. Create the next version if that has not already been done. You may need the help of a JIRA administrator to do this.
  • Update the installer configuration.
  • Update Flex web site were required:
  • Update and publish the doap_Flex.rdf file
  • Send separate [ANNOUNCEMENT] emails using your apache.org email address, preferably signing the email with the same KEY you used to sign the release. Note: Thunderbird with Enigmail for OpenPGP seems to be the easiest to configure on the Mac. AppleMail with GPGMail is another alternative. If you are not subscribed to a list with your apache address your email the email has to be accepted by the moderator of the list before it will get posted. Make sure the email is plain text and not HTML or it may be marked as spam and rejected.
    • users@flex.a.o
    • dev@flex.a.o
    • announce@a.o
  • Update the Apache Flex home page and the Apache Flex blog with the news. Encourage people to tweet about the release.
  • Update the Flex version number to be the next likely version in the code - (build.properties, many Version.as files, FlexVersion.as, MxmlConfiguration.java, VersionInfo.java). Use build/set-version.xml. See header for usage.

Clean up old version

Reference:

  • No labels