Revision as of 05:39, 14 July 2021

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 is updated with new specs and updated version numbers
   • Verify required-apis.adoc is 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.
   • Verify copyright dates have been updated in all files that mention these.
   • Verify spec release pages contain a release text including incompatible changes and feature changes, linking to the "Changelog" section at a minimum.
3. Test build locally
   • MicroProfile Clone the project and build locally before executing a release (mvn clean verify)
   • 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 (release candidate) will catch these early so they will not be as time-sensitive.
   • Verify proper MP spec PDF and HTML have been generated.

Platform releases require that the Marketing committee be notified at least two weeks in advance. This will kick off microprofile.io site updates, updated presentation, etc. This is done by opening a marketing GitHub issue noting the release date. If major/minor updates to component specifications include notable features, it is optional to create a marketing issue so tweets can be published to notify the community.

Standard Release process under MicroProfile Working Group

1. Create Component Release Record to document what release you are planning to perform (See here for Config 2.0 Release Record)
2. Ensure to create a Release Notes section on the spec by following this instruction

Milestone or Release Candidates or Micro Release

1. 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.
   • 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)
   • StagingList - A comma-separated list of the staging URLs from which you would like to pull artifacts during the build
   1. Example: https://oss.sonatype.org/content/repositories/orgeclipsemicroprofile-1384/,https://oss.sonatype.org/content/repositories/orgeclipsemicroprofile-1385/
2. 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. If the build fails but the tag and release commits have been pushed to GitHub you will need to delete the created tag and remove the release commits (force push) before running the release job again.
3. 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
      • 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. Post Release proces. Go to MicroProfile Releases Jenkins job, login with your Eclipse ID, and select Build with Parameters. This job moves the release artifacts from staging dir https://download.eclipse.org/microprofile/staging/ to microprofile dir (https://download.eclipse.org/microprofile/).
      • Release - The release you have built in the previous step. For example, 2.0-RC1
      • 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.
   5. Go to Github releases page and add links to javadoc, specification documents (html, pdf) and add release description (click here for an example. All release artificates are listed here).
      • 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.)
4. Announce the Release Candidate on the mailing list.

Major or Minor Final Releases

You must follow the following steps defined by MicroProfile Working Group to perform a final release

1. Create a Release Review issue under microprofile-wg using the template of `Specification Review Issue (e.g. MicroProfile Config 2.0 Specification Review).
2. Kick off a Jenkins build with the following 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.
   • StagingList - A comma-separated list of the staging URLs from which you would like to pull artifacts during the build
   1. Example: https://oss.sonatype.org/content/repositories/orgeclipsemicroprofile-1384/,https://oss.sonatype.org/content/repositories/orgeclipsemicroprofile-1385/
3. 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.
      • Login to Sonatype. On the left hand side, select [Staging Repositories].
      • On that tab, search for "org.eclipse.microprofile".
   2. (recommended) Update the Build Information for your Jenkins job to make it more identifiable
      • DisplayName and Description
   3. Note down the staging url for the final release and then use these info to fill in the details on the issue you created on microprofile-wg.
   4. Create a Compatible Implementation Issue on the corresponding MicroProfile repo to log the details with the proof of using the staged API, TCK jars and all TCKs passed (e.g. config 2.0 CCR)
   5. Verify the release date on the Component Release Record created earlier for being at least two weeks away, as you need to give Eclipse Foundation sufficient time to carray out IP and other checks.
   6. Follow the instruction on the Specification Review issue to send an email to PMC for PMC approval. You normally can get an approval with 1-2 days. If you are not already a member of the technology-pmc and microprofile-wg mailing lists, sign up to avoid having your emails bounce.
   7. Follow the instruction on the Specification Review issue to send an email to EMO for EMO approval. After an email is sent, a bug zilla will be created to track the release. You need to add the bugzilla link to the Specification Review issue. EMO approval normally takes longer time. It will asks for IP logs. If you need to generate IP Logs, just log onto the same site where you create Component Release Record and then click `Generate IP Log` on the right hand side. For MicroProfile specifications, if a number of specs are released at the same time, the first spec that goes into EMO process will have the IP log generated and the IP log will cover the rest specifications, because all of the MicroProfile specs share one single project. After IP log is approved, EMO will wait for MicroProfile WG ballot to conclude successfully (see the next bulletin list) before a final review is approved.
   8. (Steering Committee Member) Follow the instruction on the Specification Review issue to send an email to MicroProfile WG to initiate the ballot. The ballot lasts for 14 days but it can exit after 7 days if all of the corporate members have voted. After 14 days elapses, if the super majority vote +1, the ballot will be concluded successfully.
   9. After the ballot is concluded the result will be posted to microprofile-wg mailing list.
   10. EMO will approve the release on the date mentioned on the bugzilla.
   11. Once EMO approves, you can then log back to Sonatype and click on `Release` button to release the artifacts to Maven central.
   12. Post Release proces. Go to MicroProfile Releases Jenkins job, login with your Eclipse ID, and select Build with Parameters. This job moves the release artifacts from staging dir https://download.eclipse.org/microprofile/staging/ to microprofile dir (https://download.eclipse.org/microprofile/).
       • Release - The release you have built in the previous step. For example, 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.
   13. Go to Github releases page and add links to javadoc, specification documents (html, pdf) and add release description (click here for an example. All release artificates are listed here).
       • Update the Release title and add suitable Description to more fully describe this release.
       • Click Publish to make the release available for reviewing. (You can leave it in Draft state until you are happy with the presentation.)
   14. Announce your release by sending an email to the microprofile mailinglist
   15. Tweet about it!