MicroProfile/SpecRelease/Release

How to perform a release

These instructions assume a Mac or Linux environment. Windows is not currently supported.

Jump to #Final Release if you are performing a final version, e.g. 1.0

The following process applies to any release, including milestones, release candidates, and final release.

1. Prepare the component
   1. Ensure that the perform_release folder exists in the component's repo. This folder should contain both the prepare_release.sh and deploy_to_maven_central.sh scripts. If these are missing, copy them from the top-level microprofile-bom repo.
   2. Ensure the component's top-level pom.xml has the appropriate <scm>, and release <profile> and <plugin> stanzas. Again, compare with the top-level microprofile-bom pom.xml.
2. Prepare the candidate release
   1. Clone the respective component repo (e.g. MicroProfile BOM master repository)
   2. Run the release script, which can be found under perform_release folder in the repo (e.g. prepare_release.sh script). Be sure to specify the required env vars before. The script should create a tag (RELEASE_VERSION) and push it to the upstream repository.
      • export RELEASE_VERSION=1.0-RC1
      • export DEV_VERSION=1.0-SNAPSHOT
      • export GIT_USER='John Doe'
      • export GIT_EMAIL='john_doe@gmail.com'
3. Deploy artifacts into Eclipse repository
   1. Logon to Jenkins (your Eclipse logon should work)
   2. Go to the Jenkins release job for your component (e.g. BOM-deploy-prerelease-artifacts) and then click on "Build with Parameters"
      • If a Jenkins job does not exist for your component, then you should copy an existing job and modify according to your component. You do that by clicking on New Item on the left hand menu, and then using the "copy from" function at the bottom of that page.
4. Download the PDF document from the Jenkins job (e.g. in the workspace) and copy it to previously created github release page (e.g. https://github.com/eclipse/microprofile-jwt-auth/releases/tag/1.0-RC10) (Note: This step could be removed if we release it to a maven repo.)
   1. You can also add additional text to this github release page to help explain the release.
5. Notify MicroProfile community about the new version
   1. Send information about the created tag and artifact to review the release, e.g. on mailing-list
      • Git tag is in the source repository
      • Artifacts (API, TCK, PDF?) are in the Eclipse repository

How to perform a release of a final version

Do the steps above for a release candidate, except increase the development version instead of leaving it the same as before.

GPG utilities will be needed. These are native on Linux. If you are running on a Mac, consider installing GnuPG. Here are some good overall instructions for deploying to Maven.

If a release candidate is approved, it can be turned into final release.

1. Run the above steps for the final version, but:
   1. set RELEASE_VERSION variable to the name of the final release tag (e.g. 1.0)
   2. increase DEV_VERSION to point to the next snapshot version (e.g. 1.1-SNAPSHOT)
2. Publish the final artifact to Maven central - follow instructions in the script in the repo e.g. deploy_to_maven_central.sh
   1. Need to provide your ossrh userid and password in your .m2/settings.xml
   2. Need to provide your GPG passphrase in your .m2/settings.xml (or export GPG_TTY)
   3. Need to provide TARGET_MAVEN_REPO setting in the deploy_to_maven_central.sh (or provide the Maven Central Staging Repository in your pom.xml)
3. announce the final version
4. increase the snapshot version in master: merge the intermediary branch branch_$RELEASE_VERSION created locally by the script to master and push master:
   1. git checkout master
   2. git merge branch_$RELEASE_VERSION
   3. git push origin master