1# Contributing to `libc` 2 3Welcome! If you are reading this document, it means you are interested in 4contributing to the `libc` crate. 5 6## v1.0 Roadmap 7 8`libc` has two active branches: `main` and `libc-0.2`. `main` is for active 9development of the upcoming v1.0 release, and should be the target of all pull 10requests. `libc-0.2` is for updates to the currently released version. 11 12If a pull request to `main` is a good candidate for inclusion in an `0.2.x` 13release, include `@rustbot label stable-nominated` in a comment to propose this. 14Good candidates will usually meet the following: 15 161. The included changes are non-breaking. 172. The change applies cleanly to both branches. 183. There is a usecase that justifies inclusion in a stable release (all 19 additions should always have a usecase, hopefully). 20 21Once a `stable-nominated` PR targeting `main` has merged, it can be cherry 22picked to the `libc-0.2` branch. A maintainer will likely do these cherry picks 23in a batch. 24 25Alternatively, you can start this process yourself by creating a new branch 26based on `libc-0.2` and running `git cherry-pick -xe commit-sha-on-main` 27(`git 28cherry-pick -xe start-sha^..end-sha` if a range of commits is needed). 29`git` will automatically add the "cherry picked from commit" note, but try to 30add a backport note so the original PR gets crosslinked: 31 32``` 33# ... original commit message ... 34 35(backport <https://github.com/rust-lang/libc/pull/1234>) # add manually 36(cherry picked from commit 104b6a4ae31c726814c36318dc718470cc96e167) # added by git 37``` 38 39Once the cherry-pick is complete, open a PR targeting `libc-0.2`. 40 41See the [tracking issue](https://github.com/rust-lang/libc/issues/3248) for 42details. 43 44## Adding an API 45 46Want to use an API which currently isn't bound in `libc`? It's quite easy to add 47one! 48 49The internal structure of this crate is designed to minimize the number of 50`#[cfg]` attributes in order to easily be able to add new items which apply to 51all platforms in the future. As a result, the crate is organized hierarchically 52based on platform. Each module has a number of `#[cfg]`'d children, but only one 53is ever actually compiled. Each module then reexports all the contents of its 54children. 55 56This means that for each platform that libc supports, the path from a leaf 57module to the root will contain all bindings for the platform in question. 58Consequently, this indicates where an API should be added! Adding an API at a 59particular level in the hierarchy means that it is supported on all the child 60platforms of that level. For example, when adding a Unix API it should be added 61to `src/unix/mod.rs`, but when adding a Linux-only API it should be added to 62`src/unix/linux_like/linux/mod.rs`. 63 64If you're not 100% sure at what level of the hierarchy an API should be added 65at, fear not! This crate has CI support which tests any binding against all 66platforms supported, so you'll see failures if an API is added at the wrong 67level or has different signatures across platforms. 68 69New symbol(s) (i.e. functions, constants etc.) should also be added to the 70symbols list(s) found in the `libc-test/semver` directory. These lists keep 71track of what symbols are public in the libc crate and ensures they remain 72available between changes to the crate. If the new symbol(s) are available on 73all supported Unixes it should be added to `unix.txt` list<sup>1</sup>, 74otherwise they should be added to the OS specific list(s). 75 76With that in mind, the steps for adding a new API are: 77 781. Determine where in the module hierarchy your API should be added. 792. Add the API, including adding new symbol(s) to the semver lists. 803. Send a PR to this repo. 814. Wait for CI to pass, fixing errors. 825. Wait for a merge! 83 84<sup>1</sup>: Note that this list has nothing to do with any Unix or Posix 85standard, it's just a list shared among all OSs that declare `#[cfg(unix)]`. 86 87## Test before you commit 88 89We have two automated tests running on 90[GitHub Actions](https://github.com/rust-lang/libc/actions): 91 921. [`libc-test`](https://github.com/gnzlbg/ctest) 93 - `cd libc-test && cargo test` 94 - Use the `skip_*()` functions in `build.rs` if you really need a workaround. 952. Style checker 96 - [`./ci/style.sh`](https://github.com/rust-lang/libc/blob/main/ci/style.sh) 97 98## Breaking change policy 99 100Sometimes an upstream adds a breaking change to their API e.g. removing outdated 101items, changing the type signature, etc. And we probably should follow that 102change to build the `libc` crate successfully. It's annoying to do the 103equivalent of semver-major versioning for each such change. Instead, we mark the 104item as deprecated and do the actual change after a certain period. The steps 105are: 106 1071. Add `#[deprecated(since = "", note="")]` attribute to the item. 108 - The `since` field should have a next version of `libc` (e.g., if the current 109 version is `0.2.1`, it should be `0.2.2`). 110 - The `note` field should have a reason to deprecate and a tracking issue to 111 call for comments (e.g., "We consider removing this as the upstream removed 112 it. If you're using it, please comment on #XXX"). 1132. If we don't see any concerns for a while, do the change actually. 114 115## Supported target policy 116 117When Rust removes a support for a target, the libc crate also may remove the 118support at any time. 119 120## Releasing your change to crates.io 121 122This repository uses [release-plz] to handle releases. Once your pull request 123has been merged, a maintainer just needs to verify the generated changelog, then 124merge the bot's release PR. This will automatically publish to crates.io! 125 126[release-plz]: https://github.com/MarcoIeni/release-plz 127