Release instructions (for committers)

Eclipse Collections project follows Semantic Versioning, as described in the guidelines for contributing. You should not need to change version numbers in pom files. This is taken care of by the Jenkins release build.

Pre-requisites

1. Prepare release notes ("RELEASE_NOTE_DRAFT.md") and create PR for review
2. Subscribe to PMC
3. Sonatype Permissions

The release workflow involves the below steps:
Reference: https://www.eclipse.org/projects/handbook/#release-review

1. Create a release in project page
2. Send an email to EMC to create the release review, make it public and schedule a review. Example. They will create a GitLab issue. Example
3. Initiate PMC review by sending an email to PMC. Example
4. Initiate IP review from the project page. It will create an IPZilla. Example

Once steps from 1 through 4 are done and complete then follow the below steps:

5. Trigger Jenkins Release build. Refer to one of the variants of the release: Regular Release, Service Release

6. Trigger Jenkins Deploy builds to push to Sonatype: Sonatype Deploy

7. Trigger Jenkins Deploy builds to publish artifacts to p2 Repo: Publish p2 Repo

8. Trigger Jenkins Javadoc builds to create Javadoc: Javadoc

9. Publish to Maven Central

10. Publish Javadoc

11. Trigger Jenkins build for the new version: Start a new release

12. Publish release notes on GitHub

Regular release from master

Jenkins Build: release

Parameters

NEW_VERSION: The version number for this release, e.g. 7.0.0, 7.1.0

This build will invoke the steps below internally (assuming NEW_VERSION is 7.1.0).

1. Clone master from GitHub.
2. Update version number in the pom files, e.g. from 7.1.0-SNAPSHOT to 7.1.0.
3. Commit and push the version number changes to master.
4. Tag the previous commit, e.g. annotated tag 7.1.0.

Service (patch) release from branch

Jenkins Build: service-release

Parameters

NEW_VERSION: The version number for this release, e.g. 7.0.1, 7.0.2

SERVICE_RELEASE_BRANCH: The name of the branch for the current service release, e.g. 7.0.x

This build will invoke the steps below internally (assuming NEW_VERSION is 7.0.1 and SERVICE_RELEASE_BRANCH is 7.0.x).

1. Clone branch from GitHub, e.g. 7.0.x.
2. Update version number in the pom files, e.g. from 7.0.1-SNAPSHOT to 7.0.1.
3. Commit and push the version number changes to branch, e.g. 7.0.x.
4. Tag the previous commit, e.g. annotated tag 7.0.1.

Deploy artifacts to Sonatype for Maven Central

Jenkins Build: deploy build for the new tag.

This build will invoke the steps below internally.

1. Clone the annotated tag.
2. Run the build (clean, install)
3. Sign the jar
4. Deploy to Sonatype

Publish artifacts to p2 Repo

Jenkins Build: publish-p2-repo build for the new tag.

This build will invoke the steps below internally.

1. Clone the annotated tag.
2. Run the build (clean, install)
3. Create a zip artifact
4. Create a folder with the release tag in /home/data/httpd/download.eclipse.org/collections
5. Move the zip artifact to the folder

Create Javadoc

Jenkins Build: Javadoc build for the new tag.

This build will invoke the steps below internally.

1. Clone the annotated tag.
2. Run the build (clean, install, javadoc)
3. javadocs will be available in workspace

Publish to Maven Central

Sonatype Repo: Sonatype Repo search for eclipse-collections.

You need permissions to perform this step. Refer to How to get Sonatype Permissions

1. Once deploy to Sonatype finishes, go to Sonatype Repo and search for eclipse-collections. Sometimes it can take a while for the artifacts to be available on Sonatype.
2. Verify the artifacts and the contents. Generally check the version numbers, if jars, javadoc, etc are present. Maven Central is immutable so be careful.
3. Close the artifact
4. Release and drop the Repo
5. Sonatype will push the artifacts to Maven Central. It takes up to 6 hours for the artifacts to be available

Publish Javadoc

1. Once the Javadoc build finishes download the Javadoc artifacts from the workspace.
2. Add it to the Eclipse Collections Website repo. It is hosted at the Eclipse Foundation. Repo Link:[ssh://<EclipseId>@git.eclipse.org:29418/www.eclipse.org/collections]
3. Update all the index.html using the site folder in the Eclipse Collections GitHub Repo as reference.
4. Commit and push
5. Changes should reflect within a few minutes. Do a hard refresh of the website on your browser to verify.

Start a new release version development (a.k.a. SNAPSHOT version)

Jenkins Build: new-version

Parameters:

NEXT_VERSION: The planned next release version number, e.g. 7.1.0, 8.0.0. No need to add -SNAPSHOT which is appended by the job automatically.

RELEASE_BRANCH: Default is master. Use a branch name for service releases, e.g. 7.1.x, 8.0.x.

This build will invoke the steps below internally (assuming NEW_VERSION is 8.0.0).

1. Clone master from GitHub.
2. Update version number in the pom files, e.g. from 7.1.0 to 8.0.0-SNAPSHOT.
3. Commit and push the version number changes to master.

Publish Release Notes on GitHub

1. Open releases page on GitHub
2. Click on "Draft a new release"
3. Choose an existing tag (latest release)
4. Add the release version or tag (example 11.0.0 or 10.4.0) for "Release title"
5. Copy raw contents from "RELEASE_NOTE_DRAFT.md" and paste them into the description box
6. Review the changes (ensure formatting looks good, no typos, and release notes are accurate), click on "Save draft"
7. Preview changes from the releases page
8. Click on the release version. Scroll down and click on "Publish release"

How to get Sonatype Permissions

1. Create an id in Sonatype by visiting the Jira. Click on Sign up for Account.
2. After you have created the id, ask another committer to raise a Jira to get permission. Example
3. Once permissions are created you are set for OSS Sonatype