Skip to content

Latest commit

 

History

History
72 lines (47 loc) · 2.49 KB

RELEASING.md

File metadata and controls

72 lines (47 loc) · 2.49 KB

Releasing Swift Protobuf

When doing a release:

  1. Examine what has changed

    Github's compare UI does a reasonable job here. Open that UI and set the base to be the previous tag (X.Y.Z), and the compare can be left at main since that is what the release is cut off of.

    It usually works best to open the links for each commit you want to look at in a new browser window/tab. That way you can review each independently rather then looking at the unified diffs.

    When looking at a individual commit, at the top github will show that it was a commit on main and include a reference '#XYZ', this tells you what pull request it was part of. This is useful for doing the release notes in the next section.

  2. Validate the versions numbers

    1. Inspect Sources/SwiftProtobuf/Version.swift and ensure the number is what you expect for the next release.

      Normally we try to bump main to a new revision after each release, so this number may be fine, but if this release includes import things (api changes, etc.), it may make sense to go back and bump the major or minor number instead. If you do need to change the number: DevTools/LibraryVersions.py a.b.c.

    2. Run our tool to ensure the versions are all in sync:

      DevTools/LibraryVersions.py --validate

      This will run silently if everything was ok; if something was wrong, you'll need to figure out why and get things back in sync.

  3. Create a release on github

    Top left of the project's releases page is Draft a new release.

    The tag should be [a.b.c] where the number exactly matches one you examined in Sources/SwiftProtobuf/Version.swift.

    For the description call out any major things in that release. Usually a short summary and then a reference to the pull request for more info is enough.

  4. Publish the SwiftProtobuf.podspec

    pod trunk push SwiftProtobuf.podspec

    Note: This uses that local copy of SwiftProtobuf.podspec, but checks against the sources on github.

  5. Bump the version on main

    To help tell if someone is using main before it has been cut as a release, go ahead and bump it to a new revision:

    DevTools/LibraryVersions.py [a.b.c]

    Where c is one higher than the release that was just done.

    Make sure to commit/merge this main on github.