Skip to content

Latest commit

 

History

History
89 lines (48 loc) · 5.59 KB

ReleaseProcess.md

File metadata and controls

89 lines (48 loc) · 5.59 KB
Raw

Release Process: openlaw-core

Note this documentation is for core project maintainers and all steps may not apply to open source contributors. If in doubt, just ask! We're friendly folks. 🌈

Submitting Changes ✨

New code changes should always be introduced via a Pull Request branch:

  1. Pull latest master branch then create new branch off from master and make the changes there.

  2. If added any new tests, make sure they are all passing by running sbt test.

  3. Submit PR for merging that new branch into master. GitHub Actions will automatically attempt a build and run tests, which you can see here: https://github.com/openlawteam/openlaw-core/actions.

  4. If the build and all checks are passing, the PR can be merged to master.

Releasing to BinTray 🚀

The master branch represents the current stable set of the code, and should be considered "release-able" at any point in time.

New releases are cut from the master branch, and managed via GitHub Releases with Semantic Versioning formatted tags.

To make a release of the current status of master, follow these steps:

Drafting the release

  1. On GitHub, navigate to the main page of the repository. Under your repository name, click Releases:

    screenshot

    Then click the Draft a new release button: screenshot

    You can also click and/or bookmark this link to navigate there directly.

  2. Fill out the version tag, target and release title fields:

    release_populated

    Please note that:

    • The target must be master.
    • The version number must adhere to Semantic Version specification.
    • The version tag must begin with a v in order to indicate it is a version. Thus the full tag should be of the format v1.2.3 for version.
    • For release title please also put the identical version tag as seen above. (If left blank GitHub auto-generates very poorly.)

    SBT is configured to use these version tags as the source of truth, so treat them accordingly. 😄 In the future, we'll have a script to help out with pre-populating these values.

    How to pick a version: In most cases, you'll be doing a "patch" increment, which means just incrementing the last digit of the version. If the current version tag is v0.1.29, the next patch would be v0.1.30. If you think the release requires a larger Semantic Version bump (API changes for example), talk to others on #dev in Slack to confirm.

  3. When you're ready to publish your release, click Publish release. To work on the release later, click Save draft. screenshot

Publishing the release to BinTray

Automatically (coming soon!)

  1. Once a GitHub Release is published, our CI system will automatically start the process to publish the package to BinTray. You can monitor the progress for that process and see when it completes.

  2. Confirm that the package was successfully published with the latest version number by checking the BinTray listing.

Manually

In the very near future, the following steps will be automated and done in CI, but for right now we're doing them manually while we test:

  1. Switch to master and pull the latest. You should then also run git fetch to ensure you have the latest tags.

  2. Run sbt version and verify the version matches what you expect. If the release you just published was tagged v1.2.3, you should see 1.2.3.

    It's unlikely, but if you see a version like 1.2.3-4-gbd90214 it means the master branch has now advanced past the tagged release in commits in the time since you published the GitHub Release. You shouldn't publish these pre-release versions to BinTray. Ping @outkaj and/or @mroth and we can help resolve (most likely by manually git checkout the tag corresponding to what we want to release.).

  3. Access the BinTray credentials in our keystore (if you don't have access, ask someone who does).

  4. Run BINTRAY_USER=foo BINTRAY_PASS=bar sbt releaseBoth. (NOTE: Please never ever put these credentials in your .bash_profile or similar auto-sourced file! You are giving them away to every single process that ever executes on your workstation.)