You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Overview

This wiki records and describes the release process of Apache Eagle. The project now is in the phase of incubation, so we consider its version in format: X.Y.Z-incubating. The release history looks as the following:

VersionRelease DateGithub URLRelease Manager
0.4.0-incubatinghttps://github.com/apache/eagle/releases/tag/v0.4.0-incubatingMichael Wu <mw@apache.org>
0.3.0-incubatinghttps://github.com/apache/eagle/releases/tag/v0.3.0-incubatingHemanth Dendukuri <hdendukuri@apache.com>

Roles within a release process

Release Manager

 

  • A Release Manager (will be called RM in the followings), is someone from the community who volunteers to be and coordinates the release process. The release process is consisted of many steps, which are listed below, will mostly be carried out by the RM.
  • Typically, an RM should be a committer or PPMC member, and for sure, a contributor would also be fine to take that responsibility, except that he/she should find a PPMC as his/her mentor to make the release out.
  • The RM have to go through the policy document of apache to understand all the tasks and responsibilities of running a release.  
  • Useful materials:
    1. Frequently asked questions for making Apache releases are available on: Apache Release FAQ Page.
    2. A very helpful instructive guide page: Apache Release Management Guide

Release Steps

 

Step No.OperationAction ItemsComments
1

Sanitize JIRA

1. Before a release process starts, make sure that any issues that are "fixed" have their fix-version setup correctly.

2. Run below JIRA query to find which resolved issues do not have their fix-version set up correctly.

Resolved Issues Without Fixed Version
project = EAGLE AND status not in (Open,"In Progress",Reopened) AND fixVersion is EMPTY ORDER BY priority DESC

3. Run below JIRA query to find issues closed without release version.

Issues Closed Without Release Version
project = EAGLE AND status not in (Open,"In Progress",Reopened) AND resolution not in ("Not A Problem",Duplicate,"Cannot Reproduce",Invalid,Unresolved) AND fixVersion is EMPTY ORDER BY priority DESC

4. Modify below JIRA query template, replacing the $RELEASE_VERSION placeholder with the real release version text, and run the query to find issues that have not been fixed for the release version.

Unresolved Issues
project = EAGLE AND status in (Open, "In Progress", Reopened) AND fixVersion = $RELEASE_VERSION ORDER BY updatedDate DESC

5. Work with people to fix release related issues that are filtered in the last query, until code freezing time notified in following step.

 
2Notify Code Freezing Time PointSend an email to dev list to notify the code-freezing time point for branching, ask people to fix issues queried out from JIRA in the last step. 
3Notify Before Branching

At the code-freezing time point, send an email to dev list to notify that we are about to create branch for the release, asking people to hold off any commits until this is finished.

 

 

 
4Branching

1. Fetch and checkout from apache-eagle/develop branch and verify that HEAD is pointing to the commit that we want to be the base of the release branch. NOTE: According to history, the preferred branch name should be branch-X.Y[.Z], e.g. branch-0.4 for version 0.4.0, branch-0.3.1 for version 0.3.1, etc.

Useful Commands
# GOAL: check a branch based on remote develop branch
# $BRANCH_NAME: placeholder for branch name
# $APACHE_EAGLE_REPO: placeholder for git remote repo alias, should be pointing to
#     https://git-wip-us.apache.org/repos/asf/incubator-eagle.git
git fetch $APACHE_EAGLE_REPO
git checkout -b $BRANCH_NAME $APACHE_EAGLE_REPO/develop

2. Confirm, in the commit history, HEAD and develop branch of remote repo are at the same commit node.

Useful Commands
# GOAL: check HEAD
# $BRANCH_NAME: placeholder for branch name
git log --decorate --graph $BRANCH_NAME, HEAD

3. Push created branch to remote apache repo.

Useful Commands
# GOAL: push the creation of the branch to remote
# $BRANCH_NAME: placeholder for branch name
# $APACHE_EAGLE_REPO: placeholder for git remote repo alias, should be pointing to
#     https://git-wip-us.apache.org/repos/asf/incubator-eagle.git
git push $APACHE_EAGLE_REPO $BRANCH_NAME:$BRANCH_NAME

4. Push a tiny change to newly created branch to trigger it to be in sync with https://github.com/apache/incubator-eagle.

 
5Set Target Release Version in POMs

1. Remove "-SNAPSHOT" from POMs' version attribute by executing below 2 command.

Recommended Command
# GOAL: set version for project and its sub-modules
# $VERSION: placeholder for version, e.g. 0.4.0-incubating
mvn versions:set -DnewVersion=$VERSION -DgenerateBackupPoms=false
Alternative Command
# GOAL: set version for project and its sub-modules
# $OLD_VERSION: placeholder for old version, e.g. 0.3.0-incubating
# $VERSION: placeholder for version, e.g. 0.4.0-incubating
find . -name pom.xml | xargs sed -i "" -e "s/$OLD_VERSION-SNAPSHOT/$VERSION/"

2. This change shouldn't be updated in remote branch, it's just a local change for release.

 
6Set SNAPSHOT Version in POMs for Next Release

1. Create another local branch from "develop" branch of $APACHE_EAGLE_REPO (as mentioned previously, this placeholder should be a remote repo alias pointing to https://git-wip-us.apache.org/repos/asf/incubator-eagle.git), and checkout to the newly created branch.

2. Use maven-versions-plugin to set POMs' SNAPSHOT version for next release, e.g. target release is 0.4.0-incubating, then set version to 0.5.0-incubating-SNAPSHOT. Command should be similar to the ones in the last step.

 
7Notify After Branching

Send an email after branching is created. The email's template is as below, MAKE SURE we replace the placeholder with appropriate content, and move "To" address and "Subject" content to corresponding place before sending:

Branching Email Template
--------------------------------------
To: dev@eagle.incubator.apache.org
--------------------------------------
Subject: New release branch created: $RELEASE_BRANCH_NAME
--------------------------------------
Hi $RECIPIENT,

I've just created new release branch for upcoming $VERSION release.

Project version in develop branch has been changed to $NEW_SNAPSHOT_VERSION, please apply the update and continue opening Pull Requests to develop branch as usual. I'll cherry-pick commits to $RELEASE_BRANCH_NAME on per needed basis.
 
For hot bug fixes, please open Pull Requests to $RELEASE_BRANCH_NAME.
 
Thanks,
$RM
 
8

Generate CHANGELOG.txt

1. Checkout back to release branch (make sure the working directory is clean).

2. Open JIRA Release Note Tool, and generate the release note for the target release version. The tool automatically query out many sections based on JIRA tickets that set fix-version as the target one. Save it somewhere, named CHANGELOG.txt.

3. Modify the header line in the file, in below format, pay attention to correct the version and "incubating" clause.

Release Notes - Apache Eagle X.Y.Z (incubating)

4. Adjust the content, as well as the order of the sections inside the file, and summarize a "highlight" section. Then save changes.

5. Refer to previous version branches on github of eagle project, and copy/paste to append the content of their CHANGELOG.txt to newly created CHANGELOG.txt. NOTE: the order of different version fragment should be DESC –– the latest version should be on top of the file.

6. Copy this CHANGELOG.txt to eagle's git working directory (root directory of the project), commit it to git repo, and push it to remote apache repo on target release branch (better via Pull Request approach).

 
9Check NOTICE and DISCLAIMERCheck content of NOTICE and DISCLAIMER in the root directory of the project. 
10

Check Apache License

In root directory of the project, execute below command to confirm no license issue remaining in the project.

Check License
mvn apache-rat:check

If the execution is terminated with error messages, there usually will be a report link rendered in the console. Read the report and fix the license issues mentioned, and go on in such loops until the execution is successful without explicit error reported. Then, push changes to target release branch (better via Pull Request approach) if there is any, we can move to next step.

 

11Make Sure Source Code Only

Check that only source code are in the project, no binary files (images may be ignored, mainly jar files). The Apache Release Package Policy could be found at: Release Package Policy.

 
12

Tag Release Branch and Create Release Source Code Tar Balls

1. Build and test.

Useful Commands
# GOAL: build and test, make sure that the project can 
#       be built successfully and unit tests all pass;
#       otherwise, make changes in normal bug fix ways
#       and loop to re-build & re-test, until passed.
mvn clean test
 
# GOAL: if any changes are made, make sure again it 
#       passes license check
mvn apache-rat:check 

2. Create a tag on the branch with rc$N in tag-name. Here, rc$N means "release candidate $N", the $N should be replaced with candidate number, e.g. "rc1", "rc2", etc.

Useful Commands
# GOAL: create tag
# $VERSION: placeholder for target release version, e.g. 0.4.0-incubating
# $N: placeholder for ordinal number of release candidate, e.g. 1, 2, etc.
git tag -s -a v$VERSION-rc$N -m "Apache Eagle $VERSION release candidate $N"

3. Push tag to remote repo.

Useful Commands
# GOAL: push tag to remote repo
# $APACHE_EAGLE_REPO: placeholder for git remote repo alias, should be pointing to
#     https://git-wip-us.apache.org/repos/asf/incubator-eagle.git
# $TAG_NAME: placeholder for tag name, e.g. v0.4.0-incubating-rc1
git push $APACHE_EAGLE_REPO $TAG_NAME

NOTE: when rc2, rc3, ..., rcX are needed, we can make changes and create corresponding tags on commits respectively. To remove deprecated tags, execute:

    • git push $APACHE_EAGLE_REPO :$DEPRECATED_TAG_NAME
    • git tag -d $DEPRECATED_TAG_NAME

4. Archive the source code to a tar ball.

Useful Commands
# GOAL: archive source code to a tar ball
# $VERSION: placeholder for target release version, e.g. 0.4.0-incubating
# $N: placeholder for ordinal number of release candidate, e.g. 1, 2, etc.
git archive --format=tar --prefix=apache-eagle-$VERSION-src/ HEAD | gzip > ./apache-eagle-$VERSION-src-rc$N.tar.gz
 
13

Sanity Check

1. Copy the tar ball created in the last step to a directory, although the directory could be arbitrary one, a dedicated directory for preparing release is recommended. Let's suppose we are going to release 0.4.0-incubating, and thus use /tmp/prepare-release-0.4.0-incubating as the dedicated directory (the version text should be replaced with the actual value in practice). Then run below commands:

Useful Commands
# suppose we have copied tar ball to the dedicated directory
cd /tmp/prepared-release-0.4.0-incubating
 
# $VERSION: placeholder for target release version, e.g. 0.4.0-incubating
gunzip -c apache-eagle-$VERSION-src.tar.gz | tar xopf - 
 
git clone https://git-wip-us.apache.org/repos/asf/incubator-eagle.git
 
cd incubator-eagle
 
# $TAG_NAME: placeholder for tag name, e.g. v0.4.0-incubating-rc1
git checkout tags/$TAG_NAME
 
cd ..
 
# GOAL: make sure nothing in the tar ball is different from source code downloaded from git repo
# $VERSION: placeholder for target release version, e.g. 0.4.0-incubating
diff -r incubator-eagle apache-eagle-$VERSION-src --exclude=".git"
 
# $VERSION: placeholder for target release version, e.g. 0.4.0-incubating
cd apache-eagle-$VERSION-src
 
mvn clean install

2. Wait until the maven build finishes. If it doesn't build successfully, fix issues accordingly.

 
14

Create Signatures And Check-sums

Prerequisites
* All artifacts must be signed and check-summed. In order to sign a release we will need an OpenPGP key. We should get a key signed by a few other people. We will also need to receive their keys from a public key server. See the Apache release signing page for more details.
 
* If we've added the OpenPGP key fingerprint to our Apache profile, the key should automatically be added to https://people.apache.org/keys/group/eagle.asc
 
* md5sum and sha1sum should be installed to create check-sum and verify artifacts, run below command to install them if we don't have it on our machine:
 
    brew install md5sha1sum

1. Change our working directory to the release dedicated directory, e.g.: cd /tmp/prepared-release-0.4.0-incubating.

2. Sign artifacts and create check-sums.

Useful Commands
# GOAL: sign artifacts
# if gpg 2.X is installed, the command should start with "gpg2".
# $ARTIFACT_NAME: placeholder for artifact, e.g. apache-eagle-0.4.0-incubating-src-rc2.tar.gz
gpg --armor --output $ARTIFACT_NAME.asc --detach-sig $ARTIFACT_NAME
 
# GOAL: create md5 check-sum
# $ARTIFACT_NAME: placeholder for artifact, e.g. apache-eagle-0.4.0-incubating-src-rc2.tar.gz
md5sum $ARTIFACT_NAME > $ARTIFACT_NAME.md5
 
# GOAL: create sha1 check-sum
# $ARTIFACT_NAME: placeholder for artifact, e.g. apache-eagle-0.4.0-incubating-src-rc2.tar.gz
sha1sum $ARTIFACT_NAME > $ARTIFACT_NAME.sha1
 
15

Upload Artifact

Upload artifacts and all created check sums with signatures to https://dist.apache.org/repos/dist/dev/incubator/eagle.

Useful Commands
# suppose the release dedicated directory is: /tmp/prepared-release-0.4.0-incubating
cd /tmp/prepared-release-0.4.0-incubating
 
# checkout from apache svn that holds artifacts
svn co "https://dist.apache.org/repos/dist/dev/incubator/eagle"
 
# navigate to eagle directory and create a new directory with the release version info
# the new directory name should looks like, e.g.: 0.4.0-incubating-rc1
# $VERSION: placeholder for target release version, e.g. 0.4.0-incubating
# $N: placeholder for ordinal number of release candidate, e.g. 1, 2, etc.
cd eagle; 
mkdir $VERSION-rc$N
 
copy artifacts and generated files to the created folder
 
# commit artifacts, signatures, check-sums to apache svn
# $VERSION: placeholder for target release version, e.g. 0.4.0-incubating
# $N: placeholder for ordinal number of release candidate, e.g. 1, 2, etc.
svn add $VERSION-rc$N
svn commit -m "Upload artifacts of apache eagle $VERSION-rc$N to staging."


 
16

Update KEYS File

NOTE: This step is optional, if we already have our OpenPGP pub-key in the projects KEYS file, please skip this step.

If there is no OpenPGP pub-key the project's KEYS file, we need to execute below commands to check it in.

Useful Commands
# if gpg 2.X is installed, gpg relevant commands should start with "gpg2".
 
# GOAL: get key id of OpenPGP pub key. Execute below command and pick the one of our own
# E.g.: 
#       If the output of this command renders with: 
#         > pub   rsa4096/F1111111 2016-06-29 [SC]
#         > uid         [ultimate] Release Manager (CODE SIGNING KEY) <someone@email.com>
#         > sub   rsa4096/E2222222 2016-06-29 [E]
#       then, F1111111 in first line should be the key id.
#
#       There may be more than one sections rendered, take notice of the user info in 
#       the second line and make sure the section we're looking up is the right one.
gpg --list-keys
 
svn co https://dist.apache.org/repos/dist/release/incubator/eagle eagle-release
 
cd eagle-release
 
# GOAL: append pub-key to KEYS
# $KEY_ID: placeholder for the key id of the RM
(gpg --list-sigs $KEY_ID && gpg --armor --export $KEY_ID ) >> KEYS
 
svn commit -m "Adding OpenPGP public key to KEYS file." KEYS
 
17

Verifying A Release Candidate

Followings are the typical things we need to verify before voting on a release candidate, the RM should verify them too before calling out a vote.

  • Make sure release candidate is hosted at https://dist.apache.org/repos/dist/dev/incubator/eagle
  • Artifacts should be in format: apache-eagle-X.Y.Z-incubating.tar.gz
  • Verify Signatures: we may have to import the public key of the RM to verify the signatures. (gpg --recv-key key-id)
  • Verify git tag matches the released bits. (diff -rf)
  • Project can compile successfully from source.
  • Verify DISCLAIMER, NOTICE and LICENCE. (year etc)
  • Make sure there are no conflicting licenses (mvn clean verify, or mvn apache-rat:check)
  • Verify that no binary files, such as .jar files included in source.
 
18

Call Votes

Voting has to be done firstly in dev@eagle.incubator.apache.org mailing-list (called PPMC vote) and then in general@incubator.apache.org mailing-list (called IPMC vote) if the former passes. It usually keeps open for 72 hours or longer to receive votes for both kinds of vote, and PPMC vote can only be considered as passed if it gets at least three +1 (binding) votes without any -1 vote when the voting time range is up. Only then can the vote be closed and an IPMC vote be called.

Now, let's go through the voting process driven by emails. NOTICE: while editing the email content, e.g. replacing placeholders, we have to edit the link with the email editor, not just replace the link text, otherwise the placeholders may still be kept in the address blocking voters from referring to the url directly.

1. PPMC vote email template is as the following, MAKE SURE we replace the placeholder with appropriate content, and move "To" address and "Subject" content to corresponding place before sending:

PPMC Vote Email Template
--------------------------------------
To: dev@eagle.incubator.apache.org
--------------------------------------
Subject: [VOTE] Release: Apache Eagle $VERSION (Release Candidate $N)
--------------------------------------
Hi all,

This is a release vote for Apache Eagle, version $VERSION, release candidate $N.

Highlighted changes in this release are as the following:
  * $HIGHLIGHT_1
  * $HIGHLIGHT_2
  * etc.

Thanks to everyone who has contributed to this release.

Here's the release note: https://git-wip-us.apache.org/repos/asf?p=incubator-eagle.git;a=blob_plain;f=CHANGELOG.txt;hb=refs/heads/$BRANCH_NAME

The artifacts to be voted on are located at: https://dist.apache.org/repos/dist/dev/incubator/eagle/$ARTIFACT_DIRECTORY/

The commit to be voted upon: https://github.com/apache/incubator-eagle/commit/$COMMIT_SHA

Release tag is: https://github.com/apache/incubator-eagle/releases/tag/$TAG_NAME

Release artifacts are signed with the following key: http://people.apache.org/keys/committer/$NAME.asc

The hashes of the artifacts are as follows:
apache-eagle-$VERSION-src-rc$N.tar.gz.md5: $MD5_CHECKSUM
apache-eagle-$VERSION-src-rc$N.tar.gz.sha1: $SHA1_CHECKSUM

Please vote on releasing this package as: Apache Eagle $VERSION.

The vote is open for the next 72 hours and passes if a majority of at least three +1 PPMC votes are cast.

[ ] +1 Release this Apache Eagle $VERSION Release Candidate $N.
[ ]  0 I don't feel strongly about it, but I'm okay with the release
[ ] -1 Do not release this package because...


Thanks,
$RM

2. When it reaches the end of the voting time range, and has received three +1(binding) votes and no -1 vote, the vote can be considered as passed. Otherwise, if there is any -1 binding vote, the vote should be cancelled, and RM should reply-all with adding "[CANCEL]" in front of the subject, and giving the summarized reason. Reasonably, for failing votes, we should skip all steps left and return back to one of the above steps and re-operate to work out next release candidate (RC number should +1).

3. Then in the case of successful PPMC vote, we need to reply-all to the voting email thread, with modifying the subject by adding "[RESULT]" in front of "[VOTE]", and giving result summary within following template. MAKE SURE we replace the placeholder with appropriate content, and move "To" address and "Subject" content to corresponding place before sending:

PPMC Vote Result Email Template
--------------------------------------
To: dev@eagle.incubator.apache.org
--------------------------------------
Subject: [RESULT][VOTE] Release: Apache Eagle $VERSION (Release Candidate $N)
--------------------------------------
Hi all,

Voting is now closed and has passed with the following tally:
- PPMC +1: $PPMC_VOTERS (sum: $TOTAL)
- Others +1: $OTHER_VOTERS (sum: $TOTAL)
 
A vote will now be called on general@incubator.apache.org. Thank you all for voting for this release candidate.
 
$RM

4. Call vote in general@incubator.apache.org with below template. NOTE: in this phase, binding votes are from IPMC member, and non-binding votes are from PPMC members. MAKE SURE we replace the placeholder with appropriate content, and move "To" address and "Subject" content to corresponding place before sending:

IPMC Vote Email Template
--------------------------------------
To: general@incubator.apache.org
--------------------------------------
Subject: [VOTE] Release: Apache Eagle $VERSION
--------------------------------------
Hi all,

This is the incubator release of Apache Eagle, version $VERSION.
Highlighted changes in this release are as the following:
  * $HIGHLIGHT_1
  * $HIGHLIGHT_2
  * etc.

Thanks to everyone who has contributed to this release.

Here's the release note: https://git-wip-us.apache.org/repos/asf?p=incubator-eagle.git;a=blob_plain;f=CHANGELOG.txt;hb=refs/heads/$BRANCH_NAME

The artifacts to be voted on are located at: https://dist.apache.org/repos/dist/dev/incubator/eagle/$ARTIFACT_DIRECTORY/

The commit to be voted upon: https://github.com/apache/incubator-eagle/commit/$COMMIT_SHA

Release tag is: https://github.com/apache/incubator-eagle/releases/tag/$TAG_NAME

Release artifacts are signed with the following key: http://people.apache.org/keys/committer/$NAME.asc

The hashes of the artifacts are as follows:
apache-eagle-$VERSION-src-rc$N.tar.gz.md5: $MD5_CHECKSUM
apache-eagle-$VERSION-src-rc$N.tar.gz.sha1: $SHA1_CHECKSUM

A vote on releasing this package has already passed in Apache Eagle PPMC[1] including +1 votes from our PPPMC (XXX, XXX, XXX ...). Here is the archive of the vote: $PPMC_VOTE_ARCHIVE_LINK

Please vote on releasing this package as: Apache Eagle $VERSION.

The vote is open for the next 72 hours.

[ ] +1 Approve
[ ]  0 No opinion
[ ] -1 Disapprove (and reason ...)


Thanks,
$RM

5. When the IPMC voting time is up, according to the result, reply-all by prefixing subject with "[RESULT]" for success and "[CANCEL]" for failure. The following template could be referred, MAKE SURE we replace the placeholder with appropriate content, and move "To" address and "Subject" content to corresponding place before sending:

IPMC Vote Result Email Template
--------------------------------------
To: general@incubator.apache.org
--------------------------------------
Subject: [RESULT][VOTE] Release: Apache Eagle $VERSION
--------------------------------------
Hi all,

Voting is now closed and has passed with the following tally: 
- Binding +1s: $IPMC_BINDING_VOTERS (sum: $TOTAL)
- Non binding +1s: $PPMC_VOTERS (sum: $TOTAL)


Thanks to everyone who voted! I'll continue with the rest of the release process.
 
$RM
 
19

Close JIRA Version

We need to close the release in JIRA so that everyone knows that our version should not be used as "fixVersion" for new bugs.

  • Go to JIRA "Administration" panel of the project and hit "Versions" in left menu.
  • Table with list of all releases should appear, click on additional menu on the right of our release and choose "Release" option. 
  • Submit release date and we're done.
 
20

Upload The Artifacts For Releasing

1. In order to release we have to checkout release repository located on https://dist.apache.org/repos/dist/release/incubator/eagle/ and add release artifacts there.

Useful Commands
svn co https://dist.apache.org/repos/dist/release/incubator/eagle eagle-release
 
cd eagle-release

# $VERSION: placeholder for target release version, e.g. 0.4.0-incubating
mkdir $VERSION
 
copy artifacts to the created directory
 
rename artifacts by removing "rc$N" from the name
 
re-create md5 and sha1 check-sum (refer to previous step for how to do)
 
# GOAL: add files and check-in to svn
# add and commit artifacts, signatures, check-sums to apache svn
# $VERSION: placeholder for target release version, e.g. 0.4.0-incubating
svn add $VERSION
svn commit -m "Upload artifacts of apache eagle $VERSION for releasing."

NOTE: It may take up to 24 hours for all mirrors to sync up (http://www.apache.org/dyn/closer.cgi/incubator/eagle/)

 

2. create tag for release and check-in to git repository.

Useful Commands
# GOAL: create tag
# $VERSION: placeholder for target release version, e.g. 0.4.0-incubating
git tag -s -a v$VERSION -m "Apache Eagle $VERSION."
 
# GOAL: push tag to remote repository
# $APACHE_EAGLE_REPO: placeholder for git remote repo alias, should be pointing to
#     https://git-wip-us.apache.org/repos/asf/incubator-eagle.git
# $TAG_NAME: placeholder for tag name, e.g. v0.4.0-incubating
git push $APACHE_EAGLE_REPO $TAG_NAME

 

Optional: If there are now more than 2 releases, clear out the oldest ones (usually don't do this to avoid missing the old artifacts in case users try to access from previous announcing emails):

Useful Commands
# GOAL: remove old version from svn, the old release version will remain available in:
#    http://archive.apache.org/dist/incubator/eagle/
# $OLD_VERSION: placeholder for old release version, e.g. 0.3.0-incubating
cd eagle-release
svn rm apache-eagle-$OLD_VERSION
svn commit -m 'Remove old release $OLD_VERSION.'

NOTE: The old releases will remain available in: http://archive.apache.org/dist/incubator/eagle/

 
21Upload jars to Apache Maven Repository
Prerequisites
* RM should have the privilege to access Apache Nexus (maven repo). To achieve this, new RM may have to file a JIRA ticket to ask apache INFRA team to help grant access. Official requirement of requesting is could be found here: http://www.apache.org/dev/publishing-maven-artifacts.html#signing-up. And a sample ticket could be found at: https://issues.apache.org/jira/browse/INFRA-12409. 
 
* If you’re the first time to do release, you need update the server authentication information in ~/.m2/settings.xml. In the “servers” section, keep the structure as following, and make sure the following servers be added, and replace ${APACHE_ID}, ${APACHE_PASSWORD}, ${GPG_PASSPHRASE} with your ID, password, and passphrase:
  <servers>
    <!-- To publish a snapshot of some part of Maven. -->
    <server>
      <id>apache.snapshots.https</id>
      <username>${APACHE_ID}</username>
      <password>${APACHE_PASSWORD}</password>
    </server>
    <!-- To stage a release of some part of Maven. -->
    <server>
      <id>apache.releases.https</id>
      <username>${APACHE_ID}</username>
      <password>${APACHE_PASSWORD}</password>
    </server>
    <!-- To sign artifacts with OpenPGP. -->
    <server>
      <id>gpg.passphrase</id>
      <passphrase>${GPG_PASSPHRASE}</passphrase>
    </server>
  </servers>

1. Compile, package and upload jars to Apache Nexus server.

Useful Commands
# GOAL: set passphrase variable without putting it into shell history.
# $OLD_VERSION: placeholder for old release version, e.g. 0.3.0-incubating
# 
read -s GPG_PASSPHRASE
 
# GOAL: clean directory from both git and maven view.
git clean -xf
mvn clean
 
# GOAL: dry-run to make sure no blocking error occurs (for we have run pass tests in previous steps, just ignore the maven-test phase).
# NOTE: don't replace ${GPG_PASSPHRASE}, it's a part of the command.
mvn -Papache-release -DskipTests -Dgpg.passphrase=${GPG_PASSPHRASE} install
 
# GOLA: deploy (for we have run pass tests in previous steps, just ignore the maven-test phase).
# NOTE: don't replace ${GPG_PASSPHRASE}, it's a part of the command.
mvn -Papache-release -DskipTests -Dgpg.passphrase=${GPG_PASSPHRASE} deploy

2. When jars are uploaded successfully, we have to login with our apache account to Apache Nexus portal: https://repository.apache.org/#stagingRepositories.

3. In Nexus portal, search for line items for your uploading, whose "repository" column is usually prefixed by "orgapacheeagle-". Target the correct one with comparing the updated time.

4. Select the right one and click "Close" button. Then wait a while for backend scripts to make checks.

5. While checking process is done, and the selected one is closed successfully, the "Release" button will be enabled for us to continue. Now hit it to kick-off the release.

6. Wait until the release scripts pass.

7. Verify artifacts at: https://repository.apache.org/content/repositories/releases/org/apache/eagle/.

 
22

Announce The Release

Use apache email address (address must end with @apache.org) to send an announcing email to announce@apache.org. The following template could be referred, MAKE SURE we replace the placeholder with appropriate content, and move "To" address and "Subject" content to corresponding place before sending:

IPMC Vote Email Template
--------------------------------------
To: announce@apache.org
--------------------------------------
Subject: [ANNOUNCE] Apache Eagle $VERSION released
--------------------------------------
Hi,

The Apache Eagle (incubating) Community is happy to announce the release of version $VERSION from the Apache Incubator.

Apache Eagle (incubating) is a monitoring framework to analyze big data platforms for security and performance.
      
The release bits are available at: http://www.apache.org/dyn/closer.cgi?path=/incubator/eagle/apache-eagle-$VERSION/

The change list is available at: https://git-wip-us.apache.org/repos/asf?p=incubator-eagle.git;a=blob_plain;f=CHANGELOG.txt;hb=refs/heads/$VERSION
      
We would like to thank all contributors who made the release possible.

Disclaimer :
Apache Eagle is an effort undergoing incubation at The Apache Software
Foundation (ASF), sponsored by the Apache Incubator PMC. 
Incubation is required of all newly accepted projects until a further 
review indicates that the infrastructure, communications, and decision
making process have stabilized in a manner consistent with other 
successful ASF projects.
While incubation status is not necessarily a reflection of the 
completeness or stability of the code, it does indicate that the 
project has yet to be fully endorsed by the ASF.

Regards,
Apache Eagle (incubating) Community


 
23

Update Websites

1. Add the release to the downloads section of eagle site: https://eagle.apache.org/docs/. Currently, source code of documentation is at: https://github.com/eaglemonitoring/eaglemonitoring.github.io.

Useful Commands
# GOAL: update local git repo with the newest doc check-ins
# In this part, say, operations of updating the repo may vary depending on your working model on git, 
# e.g. fork & PR, or directly check-in/out. Anyway, the target is to get the newest code from remote
# git repo:
#     https://github.com/eaglemonitoring/eaglemonitoring.github.io
# We just list the direct model git commands here for your reference.
# $GIT_REPO_PATH: placeholder for the local git-repo path of eaglemonitoring.github.io
cd $GIT_REPO_PATH
git pull 

# GOAL: verify the result of the update
# To verify, open localhost:4000 in web browser after executing below command, then verify the updated content
jekyll serve
 
# GOAL: build site files
jekyll build
 
# GOAL: checkout existing site files from svn
svn co https://svn.apache.org/repos/asf/eagle/ eagle-site
 
cd eagle-site
 
# GOAL: copy newly built site files to svn local folder
# $GIT_REPO_PATH: placeholder for the local git-repo path of eaglemonitoring.github.io
cp -r $GIT_REPO_PATH/_site/* site/
 
# GOAL: check tracking status of files
svn status
 
# GOAL: add all untracked files
# After executing 'svn status', all untracked files are marked with "?" on the left, add them all.
# $UNTRACKED_FILE_LIST: placeholder for the untracked file name list marked by svn, separated by blank space
svn add $UNTRACKED_FILE_LIST
 
# GOAL: checkin to svn
# $COMMENT: placeholder for comment of the checkin
svn commit -m "$COMMENT"

2. Update the "News" section in the podling status page http://incubator.apache.org/projects/eagle.html, here is the refer for how to do it: http://incubator.apache.org/guides/website.html.

3. Update this page with new changes found.

 


  • No labels