Skip to content

Latest commit

 

History

History
63 lines (53 loc) · 3.77 KB

CONTRIBUTING.md

File metadata and controls

63 lines (53 loc) · 3.77 KB
Raw

Contributing

Updating libgit2

The following steps can be used to update libgit2:

  1. Update the submodule. There are several ways to go about this. One way is to go to the libgit2-sys/libgit2 directory and run git fetch origin to download the latest updates, and then check out a specific tag (such as git checkout v1.4.1).

  2. Update all the references to the version:

    • Update libgit2-sys/build.rs. There is a version probe (search for cfg.range_version) which should be updated.
    • Update the version in libgit2-sys/Cargo.toml. Update the metadata portion (the part after the +) to match libgit2. Also bump the Cargo version (the part before the +), keeping in mind if this will be a SemVer breaking change or not.
    • Update the dependency version in Cargo.toml to match the version in the last step (do not include the + metadata). Also update the version of the git2 crate itself so it will pick up the change to libgit2-sys (also keeping in mind if it is a SemVer breaking release).
    • Update the version in README.md if needed. There are two places, the Cargo.toml example and the description of the libgit2 version it binds with.
    • If there was a SemVer-breaking version bump for either library, also update the html_root_url attribute in the lib.rs of each library.

  3. Run tests. cargo test -p git2 -p git2-curl is a good starting point.

  4. Run systest. This will validate for any C-level API problems.

    cargo run -p systest

    The changelog at https://github.com/libgit2/libgit2/blob/main/docs/changelog.md can be helpful for seeing what has changed. The project has recently started labeling API and ABI breaking changes with labels: https://github.com/libgit2/libgit2/pulls?q=is%3Apr+label%3A%22api+breaking%22%2C%22abi+breaking%22+is%3Aclosed Alternatively, running git diff [PREV_VERSION]..[NEW_VERSION] --ignore-all-space -- include/ can provide an overview of changes made to the API.

  5. Once you have everything functional, publish a PR with the updates.

Release process

Checklist for preparing for a release:

  • Make sure the versions have been bumped and are pointing at what is expected.
    • Version of libgit2-sys
    • Version of git2
    • Version of git2-curl
    • git2's dependency on libgit2-sys
    • git2-curl's dependency on git2
    • The libgit2 version probe in libgit2-sys/build.rs
    • Update the version in README.md
    • Check the html_root_url values in the source code.
  • Update the change logs:

There is a GitHub workflow to handle publishing to crates.io and tagging the release. There are two different ways to run it:

  • In the GitHub web UI:
    1. Go to https://github.com/rust-lang/git2-rs/actions/workflows/publish.yml (you can navigate here via the "Actions" tab at the top).
    2. Click the "Run workflow" drop-down on the right.
    3. Choose which crates to publish. It's OK to leave everything checked, it will skip if it is already published. Uncheck a crate if the version has been bumped in git, but you don't want to publish that particular one, yet.
    4. Click "Run workflow"
  • In the CLI:
    1. Run gh workflow run publish.yml -R rust-lang/git2-rs