Skip to main content
Jump to: navigation, search

MicroProfile/SpecRelease/Release

How to perform a release

Pre-Release Review Steps

  1. Spec release creation
    • Verify a spec release has been created for each new or update spec.
    • For missing spec releases, notify spec teams by logging a github issue on that project and, if time-sensitive, contacting directly.
  2. In MicroProfile project source
    • NOTE: The build process will update the pom.xml <version>X.Y-SNAPSHOT</version> tags automatically, so do not manually change these.
    • Verify pom.xml has been updated with new spec dependencies (when a new specification is added). Spec teams should provide this, but worth the double-check.
    • Verify pom.xml has updated spec version numbers in the properties section. Spec teams should update this, but worth the double-check.
    • Verify architecture.adoc and required-apis.adoc updated with new specs and updated version numbers
    • Verify README.adoc is up-to-date with example POM file version number and any other spec changes.
  3. Test build locally
    • MicroProfile Clone the project and build locally before executing a release (mvn clean install)
    • Look at log output. Even without errors, there may be warnings (improper javadoc annotations, etc). Notify spec teams by logging a github issue on that project and, if time-sensitive, contacting directly. A CR (candidate release) will catch these early so they will not be as time-sensitive.

New release process

This new release process was prepared by John Ament (version 2). It uses a single MicroProfile Releases Jenkins job.

The release steps are:

  1. Update MicroProfile calendar with required dates. (More info coming...)
  2. Ensure to create a Release Notes section on the spec by following this instruction
  3. Get 3rd dependency CQs approved by following the dependency process
  4. Go to MicroProfile Releases Jenkins job, login with your Eclipse ID, and select Build with Parameters. This job builds artifacts, specification documents, and creates staging repository in Nexus. For a final release, please skip to the "Final Release" step below.
    • Snapshot - The current development <version> identifier for your pom.xml. For example, 2.0-SNAPSHOT
    • Release - The desired release you are attempting to build. For example, 2.0-RC1
    • Tag - The desired tag for the release you are attempting to build. Normally, the Tag is the same as the Release. For example, 2.0-RC1
    • Rev - Draft or Final. Use Draft for the RCx releases (ie. 2.0-RC1). Use Final when doing the Final release (ie. 2.0).
    • Module - Select the repository you are attempting to build. If your repo is not listed, you will need to modify the configuration in the microprofile-parent repo.
    • Branch - Normally, you will build from "master", but some components have multiple branches (ie. 1.x-branch in the microprofile repository)
  5. If this is your first Jenkins build for your component, you may need to debug your configuration to get a successful build. You may need to examine your build/console output and you may need to adjust your pom.xml to get the proper configuration. Check out this githib issue for more information on the specific updates required. Or, reference existing working repositories like microprofile-jwt-auth or microprofile for examples.
  6. Once the build succeeds...
    1. (recommended) Smoke test the release by building a project that depends on it. To do this, you'll need to temporarily add the staging repository for the release to that projects repositories in the pom. The staging repository URL can be found in the Sonatype Nexus Repository Manager, it will have a URL like https://oss.sonatype.org/content/repositories/orgeclipsemicroprofile-1126, though this URL will be different for each release.
    2. Release the staging repository to Maven central (mandatory if a final release, recommended if non final):
      • Login to Sonatype. On the left hand side, select [Staging Repositories].
      • On that tab, search for "org.eclipse.microprofile".
      • Select the appropriate staging repositories and select the "Release" action along the top action bar.
      • Leave the default action to drop the staging repositories after completing this action and click [Submit]. Once complete, it usually takes around 10 minutes (but can take longer) to sync the release across Maven Central's CDN.
    3. (recommended) Update the Build Information for your Jenkins job to make it more identifiable
      • DisplayName and Description
    4. Go to Github releases page and upload specification documents (html, pdf) and add release description.
      • Update the Release title and add suitable Description to more fully describe this release.
      • If this is a Release Candidate driver, be sure to click the box that says ``This is a pre-release``.
      • Click Publish to make the release available for reviewing. (You can leave it in Draft state until you are happy with the presentation.)
  7. Announce the Release Candidate on the mailing list.
  8. If this is a Final release, just a few updates/additions to the above instructions...
    1. Build Parameters
      • Snapshot - The next development <version> identifier for your pom.xml. For example, 2.1-SNAPSHOT, if you are now releasing the final 2.0 version.
      • Release - The final release you are attempting to build. For example, 2.0
      • Tag - The desired tag for the final release you are attempting to build. The Tag is the same as the Release. For example, 2.0. If, for some reason, the final release build fails, this tag is still in use. You need to go to the corresponding repository and delete the tag, e.g. 2.0, and then kick off another release.
      • Rev - Draft or Final. Use Final when doing the Final release.
    2. Since this is the Final release, ensure that the ``This is a pre-release`` box is not checked when publishing the github Release.
    3. Release the Sonatype Staging Repo to make the final release available in Maven.
    4. Update MicroProfile Impl page: https://wiki.eclipse.org/MicroProfile/Implementation
    5. Update MicroProfile Downloads page: https://projects.eclipse.org/projects/technology.microprofile/downloads
    6. Tweet about it!
    7. Announce the Final release on the mailing list and go have a beer!

Troubleshooting

  • In the event that the build portion of the Jenkins task succeeds, but fails to publish to Sonatype - for example, the Jenkins build may fail with a "Gateway Timeout" - this may leave the repository in an inconsistent state. The release tooling will likely have created a new commit for the release and tagged the branch. Once the branch is tagged, then it is not possible to run through the release tooling again with the same tag. The following steps should help resolve this issue:
    1. Log into Sonatype and look for your (botched) release under [Staging Repositories]. If it exists, [Drop] it.
    2. Next, proceed to your project repository in GitHub, then navigate to the [Code] tab, then the [releases] sub-tab. If the botched release exists there, you can delete it by clicking on the release name, and then clicking the [Delete] button. Likewise, click on the [Tags] button and similarly delete the tag.
    3. You will need to add a commit to the repository before the release tooling will create a new release. If there is a typo in the javadoc, this is a great opportunity to fix it. :)
    4. Now you should be ready to restart the release process above - and hopefully you'll have better luck this time.

Older release process (obsolete - do not use)

This is the version 1 of the release process. It uses scripts run on a local computer manually build artifacts, push the changes to GIT and release artifacts into Maven Central. A Jenkins job per specification is used to release non-final artifacts into Eclipse maven repository instead of Maven Central. This release process is now deprecated in favor of version 2.

Note.png
These instructions assume a Mac or Linux environment. Windows is not currently supported.
Note.png
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

How to perform a release of a final version (obsolete - do not use)

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

Note.png
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)
    4. You may need to go the Sonatype site and manually Release the artifacts from the Staging repository.
  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

Back to the top