Skip to content

Latest commit

 

History

History
52 lines (42 loc) · 3.01 KB

RELEASING.md

File metadata and controls

52 lines (42 loc) · 3.01 KB

Releasing OSHI

Credentials

Snapshots

  • Other than during releases, the version number in the pom.xml should end in -SNAPSHOT
  • A GitHub Action deploys snapshots for pushes to the master branch. Snapshot releases may also be manually deployed using mvn clean deploy

Prepare

  • Make sure tests pass on all configured CI operating systems.
  • Manually run tests on any non-covered OS using mvn clean test.
  • Review SonarQube for any bugs.
  • Choose an appropriate version number for the release
    • Proactively change version numbers in the download links on README.md.
    • Copy README.md to src/site/markdown/README.md
      • HTML-escape &, <, and > in any links in the site version
    • Change "Next" or in-progress version in CHANGELOG.md to this new version.
    • Move "Your contribution here." to a new empty "Next" section
    • Commit changes as a "prep for x.x release"

Release

  • See this page for a summary of the below steps

  • mvn clean deploy

    • Do a final snapshot release and fix any errors in the javadocs
    • If license headers are rewritten as part of this deployment, commit the changes

  • mvn release:clean

    • Takes a few seconds

  • mvn release:prepare

    • Takes a few minutes
    • This will ask for the version being released, removing -SNAPSHOT
    • This will suggest the next version, increment appropriately

  • mvn release:perform

    • Takes a few minutes.
    • This pushes the release to the OSSRH staging repository
    • This also pushes to gh_pages

  • Log on to Nexus and release the deployment from OSSRH to the Central Repository.

  • Add a title and release notes to the tag on GitHub and publish the release to make it current.

  • Repeat all of the above steps on the java11 branch, after cherry-picking recent commits.

  • As development progresses, update version in pom.xml using -SNAPSHOT appended to the new version using Semantic Versioning standards:

    • Increment major version (x.0) for API-breaking changes or additions
    • Increment minor version (x.1) for substantive additions, bugfixes and changes that are backwards compatible
    • Increment patch version (x.x.1) for minor bugfixes or changes that are backwards compatible