GPG

If you are not already a member of the Web Of Trust (WOT) it would be a good idea to do so. You can read more about key signing here.

Ensure that you have setup your ssh keys on people.apache.org, otherwise you'll have to enter your login password a number of times (best use ssh-agent for this as well). A good overview of this process can be found here (ssh-copy-id and ssh-agent in particular).

NOTE: when doing a release you will be asked for your PGP password multiple times unless you set up the gpg-agent. Mac users have reported trouble getting gpg-agent to work. You can also set your gpg-password in the Maven settings file (see below).

Maven Settings

Your Maven settings (~/.m2/settings.xml) file should have the following (note: curator-website-checkout-path is used as a temporary path when deploying the Curator website):

Versioning

Essentially, it tells you the API compatibility between multiple dependencies. For example,

If you have version 1.0.0 and 1.0.1, you can use either one and you will not run into errors due to API conflicts (i.e. in Java, no ClassNotFound or NoSuchMethod type exceptions)

If you have 1.0.0 and 1.1.0, you can replace 1.0.0 with 1.1.0 and you will not have errors due to API conflicts. If you try to swap 1.0.0 in place of something that depends on 1.1.0, however, you *might* have errors due to API conflicts. I.e. you can go forward without errors, but not backwards

If you have 1.0.0 and 2.0.0, you will likely have errors due to API conflicts if you replace either one with the other.

Make sure you choose an appropriate version for each release. The Maven build will output messages if there are API compatibility issues (look for the "clirr-maven-plugin" messages).

Create a branch for the PR: git checkout -b <branch name> - the branch name is usually the JIRA ID of the issue

Pull the changes from the PR: git pull https://github.com/<users-name>/exhibitor.git <branch>

Test, updated, etc. the change. Periodically push the change to the main repo. For the initial push: git push -u origin <branch name>

If the change is accepted, merge it into the master branch and push the master branch. This will automatically close the GitHub PR. NOTE: Please use git merge --squash as this makes it easier to read the history and do cherry-picks.

Curator 2.0

The master branch of our Git repo represents Curator 3.x. However, Curator 2.x is still an active project. Whenever a PR is merged into master it must also be considered as a candidate for Curator 2.0. Any PR that is compatible with Curator 2.0 should be cherry picked into the Curator 2.0 branch via: git cherry-pick <branch name> - i.e. if you are merging a branch named CURATOR-123 and the change applies to Curator 2.0, merge into into the 2.0 branch by doing:

git checkout CURATOR-2.0git cherry-pick CURATOR-123git push

Declining Pull Requests

If a Curator committer wants to close a PR without merging, it can be accomplished via:

Jenkins

Jira

Maven Checks

Regardless of which IDE you use, you should periodically perform a mvn clean install to validate that the various configured checks (such as license headers, etc.) are passing as well as the unit tests.

Releasing Curator

To release Curator, the following steps must be followed:

The binary artifacts must be staged

The Apache release must be staged

The release must be voted on

If the vote succeeds:

The Apache release must be promoted

The binary artifacts must be released

Prepare the Release

Do a dry run of the release/prepare step by executing mvn -P apache-release release:prepare -DdryRun=true. The dry run will not commit any changes back to Git and gives you the opportunity to verify that the release process will complete as expected. If you need to cancel, execute mvn release:clean and then reset via git reset --hard.

Verify that the release process completed as expected:

The release plugin will create pom.xml.tag files which contain the changes that would have been committed to SVN. The only differences between pom.xml.tag and its corresponding pom.xml file should be the version number.

If other formatting changes have been made you should review the changes and then commit and push them.

Once any failures or required updates have been committed to svn, rollback the release prepare files: mvn release:rollback

Execute the release/prepare step for real this time

You'll be prompted for the same version information and optionally your GPG passphrase again

Select Staging Repositories under the Build Promotion section on the left hand side

Select the repository from the main window

Select the content tab at the bottom of the screen and navigate through the artifact tree and double check things.

Close the Nexus staging repo by clicking on the curator repo and clicking the "Close" button.

IMPORTANT: Do NOT release the binaries yet

Stage the Apache Release

Create the stageable source artifacts

Checkout the release: git checkout apache-curator-X.X.X

mvn -P apache-release clean install

git checkout master

Locate the artifacts in your local Maven repository. On Mac/*nix this will be ~/.m2/repository/org/apache/curator/apache-curator/.... The remainder of the directory will be the version being released. In the directory you will find 4 files that need to be staged:

How to Publish the Curator Website

Assuming you have a clean compile/install of Curator, from the root of the Curator directory:

git checkout master
mvn site site:stage

Have a look at the staged site and make sure it's good. Then:

cd to the curator-website directory

(optional) delete existing content: rm -fr *

cp -r [curator source directory]/target/staging/* .

Delete any old files from svn:

svn st | grep ^! | awk '{print " --force "$2}' | xargs svn rm

Add any new files to svn:

svn add --force * --auto-props --parents --depth infinity -q

Commit the changes:

svn commit -m "Update for Curator version N.N.N"

You may need to make sure you've authenticated to the Apache Subversion server before you can push the site, else you may get an error along the lines of authorization failed: Could not authenticate to server: rejected Basic challenge. More reading material on how to secure your SVN credentials can be found here.

Also note if you get an error complaining that Server certificate verification failed: issuer is not trusted, you can add the repo certificate to the list of certificates accepted to your local svn client by simply listing the repository and accepting the cert permanently.