Discusses the steps used to create a new iota release. You have to be a iota committer to create a release.

Create PGP Key

If you haven’t done so already, then you need to create a PGP key so that you can sign the release. Please refer to:http://www.apache.org/dev/openpgp.html#generate-key.

 

Please remember to store your private key in a secure place.

Example: Create PGP Key
gpg --gen-key   (verify that sha1 is avoided (last on list - see above web site)
gpg -k  (shows public key)
gpg -K (shows private key)

Upload Public Key

Upload your public key to a public key server. We recommend using https://pgp.mit.edu/.

Example: Upload Public Key
gpg --send-keys <keyID> --keyserver pgp.mit.edu

Generate Revocation Certificate

Create a revocation certification using the instructions at: http://www.apache.org/dev/openpgp.html==revocation-certs.

 

Please remember to store it in a secure place separate from your PGP keys.

Example: Generate Revocation Certificate
gpg --output revoke-<keyID>.asc --armor --gen-revoke <keyID>

Add PGP to KEYS File

Do the following:

Example: Add PGP to KEYS File
svn co https://dist.apache.org/repos/dist/release/incubator/iota traf_release
cd traf_release
gpg --list-sigs <keyID> >> KEYS
gpg  --armor --export <keyID>
svn commit -m "added new public key to KEYS file"

Get Your Key Signed

Link into the Web of Trust by having someone else sign your key. 

You can sign other people's keys, but you must verify their identity in person and make sure the key fingerprint matches. See ASF guide for more info.

Prepare For Release

Prepare New Release

  1. Send a message out to the community indicating that a new release is being planned. In this message, indicate what is planned for the release and when the release is scheduled.
  2. Give contributors enough time to assimilate this information so they can make plans to deliver their changes. Recommend giving the community several weeks notice.
  3. Review open issues and planned features; determine what Jiras should be included in the release.

Verify Release Requirements

You need to ensure that:

  • A DISCLAIMER file exists in the top level directory containing correct information. Please refer to:http://incubator.apache.org/guides/branding.html==disclaimers.
  • NOTICE and LICENSE files exist in the top level directory which includes all third party licenses used in the product. Please refer to: http://www.apache.org/dev/licensing-howto.html.
  • A README file exists and is up to date in the top level directory describing the release.
  • The source release contains source code only, no binaries.
  • The provenance of all source files is clear.
  • All source files have Apache license headers, where possible. Where not possible, then the exceptions are written up in the RAT_README file located in the top level directory.
  • RAT report is clean.
  • Copyright dates are current.
  • Build instructions are provided and can be run successfully.
  • Test instructions are provided and can be run successfully.

Create Release Branch

Prior to releasing, send a message to the community indicating that a new release is imminent and that a new branch will be created to build the artifacts.

git branch release1.0 apache/master
git push apache release1.0:release1.0

 

Make sure that check-in automated testing is set up for new release.

After the new release branch is created, send another message to the community indicating that the branch is available and the deliveries will be monitored. Allow deliveries on the main branch to continue.

It is now time to change the release number on the master branch to the next release number, to avoid confusion with the release branch.

Create Release Notes

Find someone to pull together release notes to summarize content of the release. A starting point is the automated JIRA release notes. Go the project overview, select the release, and use the Release Notes button to get a link to the list.

For the RC votes, a link to JIRA is okay, but meanwhile, the markdown page to be posted on the website(http://iota.incubator.apache.org/release-notes.html) should be prepared and be posted to the site by the time the release announcement is due.

Updates to the release download page also need to be prepared. http://iota.incubator.apache.org/download.html

Guidelines are available: http://www.apache.org/dev/release-download-pages

Create a Release Candidate

Verify that all required changes have been delivered.

Create Artifacts

iota uses git as its repository. When a new version is created, mark the repository with the tag to make sure it source tar can be recreated.

Create Tag

Example: Release x.x.x and release candidate 1 (rc1)
git tag -a x.x.xrc1 apache/<releaseX.X>
git show x.x.xrc1
git push apache tag x.x.xrc1
git checkout x.x.xrc1
source env.sh
make package-src

Once completed, a new source tar file exist in the distribution directory. 

Binary Artifacts

The convenience binary artifacts should be built from the source tar file, not from a git workspace. Best to create the build in a nice clean environment per the build instructions.

However, when creating these official binaries, we do want some version information built into the binaries.In the git workspace checked out to the tag, run this describe command:

  • git describe --long --tags --dirty --always

The output should be a one-line string. Set the "PV_BUILDID" environment variable to that value and "PV_BRANCH" to the release branch name.

Example: Official Build
tar xvf apache-iota-x.x.x-incubating-src.tar.gz
cd apache-iota-x.x.x-incubating
cd core/sqf ; source sqenvr.sh ; cd ../..
export PV_BUILDID=x.x.xrc2-0-g12345ab
export PV_BRANCH=releaseX.X
make package
sqvers   # check version info

Create Artifact Checksums and Signatures

Assumption

You’ve already created the signing key and registered it at the https://pgp.mit.edu/ repository.

Example: Create Artifact Checksums and Signatures
gpg --armor --output apache-iota-x.x.x-incubating-src.tar.gz.asc --detach-sig apache-iota-x.x.x-incubating-src.tar.gz
gpg --verify apache-iota-x.x.x-incubating-src.tar.gz.asc
md5sum apache-iota-x.x.x-incubating-src.tar.gz > apache-iota-x.x.x-incubating-src.tar.gz.md5
sha1sum apache-iota-x.x.x-incubating-src.tar.gz > apache-iota-x.x.x-incubating-src.tar.gz.sha

For each of the tarfiles in the distribution directory, create checksums and signature files using same methods as above.

Test Artifacts

Build and Test Source tar File

 

Build and test the source tar file using the Build Source instructions. You should perform this test on the following environments:

 

  • Test build on a fresh VM.

  • Test build using the src tar file created above

Compare Tagged Version with Source tar File

Compare the code from the source tar file with the tagged version to make sure they match.

Example: Compare Tagged Version
mkdir artifacts
mv incubator-iota/distribution/* artifacts/   # save artifacts
cd incubator-iota ; git clean -xdf            # clean any built files
git checkout x.x.xrc1                              # be sure we are on tagged version
cd ..
tar zxf artifacts/apache-iota-x.x.x-incubating-src.tar.gz
diff -r incubator-iota apache-iota-x.x.x-incubating

Compare the two versions; for example, by using diff, or a GUI tool such as BCompare and the "Folder Compare Report" feature.

 

The source package may have a generated LICENSE file and exclude git folders, etc per the .gitattributes file.

Verify Apache Requirements

Verify checksums and signatures using the Verify Signature instructions below. Ensure that the high-level directory contains valid version of:

  • DISCLAIMER
  • LICENSE
  • NOTICE
  • RAT_README
  • README

Stage Artifacts

Once all the artifacts have been created and tested, then it’s time to stage them. Upload the artifacts to the https://dist.apache.org/repos/dist/dev/incubator/iota directory.

  1. Make sure svn exists. (It can be downloaded using yum.)

    which svn
svn --version # (version 1.6.11 works)

      

  2. Create a directory to store the svn repository.

  3. Checkout source code. This creates a directory called iota.

    svn co https://dist.apache.org/repos/dist/dev/incubator/iota

      

  4. cd iota
  5. Create a new directory for the release: mkdir iota-x.x.x-RCx
  6. Copy the artifact files to the incubating directory.
  7. Ensure that you do an svn add for the new directory and all files.
  8. Ask for a review of the changes.

  9. Commit your changes.

    svn status
svn commit -m "message..."

    Go to https://dist.apache.org/repos/dist/dev/incubator to see if your changes were committed.

  10. (Future Release) Also stage JDBC jar file in maven repo. http://www.apache.org/dev/publishing-maven-artifacts.html

Verification

All artifacts have been uploaded to the staging area.

Verify Signature

Download all the artifacts from the staging area including: 

apache-iota-x.x.x-incubating-src.tar.gz
apache-iota-x.x.x-incubating-src.tar.gz.asc
apache-iota-x.x.x-incubating-src.tar.gz.md5
apache-iota-x.x.x-incubating-src.tar.gz.sha
Check signatures and checksums.
  • apache-iota-x.x.x-incubating-src.tar.gz.asc

     

    # View public key
gpg apache-iota-x.x.x-incubating-src.tar.gz.asc

# Expect
gpg: Signature made Tue 03 Nov 2015 12:59:10 AM UTC using RSA key ID A44C5A05
gpg: Can't check signature: No public key

# Extract public key from key ID returned above
gpg --keyserver pgpkeys.mit.edu --recv-key A44C5A05

# Expect:
gpg: requesting key A44C5A05 from hkp server pgpkeys.mit.edu
gpg: /home/centos/.gnupg/trustdb.gpg: trustdb created
gpg: key A44C5A05: public key "Jane Doe (CODE SIGNING KEY) <jdoe@apache.org>" imported

# Verify signature
gpg --verify apache-iota-x.x.x-incubating-src.tar.gz.asc

# Expect:
gpg: Signature made <date> using RSA key ID A44C5A05
gpg: Good signature from "Roberta Marton (CODE SIGNING KEY) <rmarton@apache.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
  • apache-iota-x.x.x-incugating-src.tar.gz.md5

     

    md5sum -c apache-iota-x.x.x-incubating-src.tar.gz.md5

# Expect:
apache-iota-x.x.x-incubating-src.tar.gz: OK
  • apache-iota-x.x.x-incubating-x.x.x-incubating-src.tar.gz.sha

     

    sha1sum -c apache-iota-x.x.x-incubating-src.tar.gz.sha

# Expect:
apache-iota-x.x.x-incubating-src.tar.gz: OK

Verify Apache Requirements

Next, run rat to make sure all files have Apache copyrights.

Example: Run RAT check
java -jar /path/to/apacherat.jar -E .rat-excludes -d $(pwd)

 

 

Complete Release

Ask for a vote from the Apache iota community (podling)

 Send an email to dev@iota.incubator.apache.com asking for a vote from the Apache iota community.

  • Subject: [VOTE] Apache iota release x.x.x ready for release - release candidate x
  • Message contents (see example of how other incubator projects create their contents)
    • request to vote
    • thanks to all contributors
    • link to the artifacts
    • link to git repository and its tag
    • link to verify, build, and test instructions 
    • link to release notes
    • key of person who signed the release
    • if not the first release candidate, then any changes from previous vote on the same release

The vote is open for 72 hours.  If any -1 votes returned, resolve the issue which may require the current vote to be cancelled and propose a new release candidate.  At least three +1 votes are needed to take this to the next phase. Recommend getting at least one mentors to vote on the release.

If problems arise which requires a new vote, resend the original VOTE email to dev@iota.incubator.apache.com , prepend [CANCEL] to the title and add a short explanation why the vote was cancelled.

  • Subject: [CANCEL][VOTE] Apache iota release x.x.x ready for release - release candidate x

If the vote is successful (no -1's and at least three +1's) after 72 hours, report the results of the vote:

  • Subject: [RESULT][VOTE] Apache iota release x.x.x ready for release - release candidate x

Ask for a vote from the Apache Incubator community

This step is similar for asking for a vote from the Apache iota community.  See http://incubator.apache.org/guides/releasemanagement.html#note-votes for more details.

Send an email to general@incubator.apache.com asking for a vote from the Apache Incubator community. Include link to original vote results, as well as all the original info.

Once the vote is closed successfully, move on to Final Release.

Final Release

Git Label

  • Get the latest from repo:
    • git fetch –all
  • Create a release tag on the final release candidate. The rel/ folder is protected, so that no one can remove the tag. The tag should be based on the last RC tag.
    • git tag –m "Release x.x.x Final"    rel/x.x.x      x.x.xrcX
    • Example (create rel/1.3.0, based on RC5 tag)
      • git tag –m "Release 1.3.0 Final"   rel/1.3.0    1.3.0rc5 
  • Verify tag is on correct commit:
    • git log –decorate rel/x.x.x
  • Push the tag to Apache repo (requires committer permissions):
    • git push apache tag rel/x.x.x

Upload Release Artifacts

Update Project Web Site

Add the Release Notes to the web site and update the downloads page.

Files to be updated are docs/src/site/markdown. They can be previewed by generating the HTML files (mvn site) and viewing them in browser.

Submit pull request to master branch.

Wait for Mirrors to Synch

Wait 24 hour for the artifacts to be distributed to the mirrors. Go to www.apache.org/dyn/closer.lua, click on one or more of the mirror locations, click on incubator and then iota.  Under iota, you should see the release artifacts.

Announce the Release

A message should be sent to both general@incubator.apache.org and users@iota.incubator.apache.org lists.

Title: [ANNOUNCE] Release Apache iota x.x.x-incubating

Contents should include release summary and/or link to release notes as well as link to download site. During incubation, there is another disclaimer to add at the end of the mail. See previous release announcements.

  • No labels