github.com/cilium/ebpf@v0.15.1-0.20240517100537-8079b37aa138/docs/ebpf/contributing/new-feature.md (about)

     1  # Adding a new feature
     2  
     3  We're very much looking for contributions which flesh out the functionality of
     4  the library.
     5  
     6  1. Have a look at the [architecture](architecture.md) of the library if you
     7     haven't already.
     8  2. [Join](https://ebpf.io/slack) the
     9     [#ebpf-go-dev](https://cilium.slack.com/messages/ebpf-go-dev) channel to
    10     discuss your requirements and how the feature can be implemented.
    11     Alternatively open a new Discussion if you prefer to not use Slack.
    12     The most important part is figuring out how much new exported API is necessary.
    13     **The less new API is required the easier it will be to land the feature.**
    14     Also see [API stability](#api-stability).
    15  3. (*optional*) Create a draft PR if you want to discuss the implementation or have hit a problem. It's fine if this doesn't compile or contains debug statements.
    16  4. Create a PR that is ready to merge. This must pass CI and have tests.
    17  
    18  ## API stability
    19  
    20  There is an emphasis on compatibility even though the library doesn't guarantee
    21  the stability of its API at the moment.
    22  
    23  1. If possible, avoid breakage by introducing new API and deprecating the old one
    24     at the same time. If an API was deprecated in v0.x it can be removed in v0.x+1.
    25     This is especially important if there is no straighforward way to convert
    26     from the old to the new API.
    27  2. Breaking API in a way that causes compilation failures is acceptable but must
    28     have good reasons.
    29  3. Changing the semantics of the API without causing compilation failures is
    30     heavily discouraged.