github.com/inspektor-gadget/inspektor-gadget@v0.28.1/docs/devel/release-process.md (about) 1 --- 2 title: Releasing 3 weight: 220 4 description: > 5 How to release Inspektor Gadget 6 --- 7 8 The Inspektor Gadget release process is heavily automated, however some manual steps are still 9 required. This guide describes the process to make a new release of Inspektor Gadget and includes 10 some information of what to do in case something goes wrong. 11 12 Be sure you have a general understanding of the whole release process before starting to follow the 13 steps described here. It's also important to stay aware as a mistake could cause issues for our 14 users. 15 16 ## Making a new release 17 18 0. Be sure tests on main branch are passing, please fix them if not. 19 1. Switch to the main branch and pull latest changes 20 21 ```bash 22 $ git checkout main 23 $ git pull origin 24 ``` 25 26 Double check that the latest commit is the right one to make the release. 27 28 2. Tag the new version. 29 30 ```bash 31 $ git tag v0.x.0 32 ``` 33 34 3. Push tag to remote 35 36 ```bash 37 $ git push origin v0.x.0 38 ``` 39 40 4. Verify that the CI for the tag passed 41 42 5. Once the CI is done, go to https://github.com/inspektor-gadget/inspektor-gadget/releases and edit 43 the created draft release. Then click `Generate release notes` and update them to match the format used 44 for other releases: 45 46 ``` 47 < Relevant changes > 48 49 ### General Improvements 50 ### Bug Fixes 51 ### Documentation Improvements 52 ### Testing and Continue Integration 53 ``` 54 55 6. Once satisfied with the release notes, publish the draft release as public release. 56 57 7. Verify that the CI created a pull request in 58 [krew-index](https://github.com/kubernetes-sigs/krew-index/pulls) and that it was merged 59 automatically by the bot 60 61 8. Send an announcement on the [#inspektor-gadget](https://kubernetes.slack.com/archives/CSYL75LF6) Slack channel 62 63 ## Post release tasks 64 65 - Create a branch for this release named `release-v0.x`, this will be used as stable branch where fixes would be backported: 66 67 ```bash 68 $ git checkout -b release-v0.x 69 $ git push --set-upstream origin release-v0.x 70 ``` 71 72 - Check if the [milestone for the release](https://github.com/inspektor-gadget/inspektor-gadget/milestones) still 73 contain open issues. If so, move them as appropriate. Close the milestone. 74 75 - Check the automatic pull request updating the [Inspektor Gadget website](https://inspektor-gadget.io/) and merge as appropriate ([example for v0.22.0](https://github.com/inspektor-gadget/website/pull/27)). 76 77 - Update other projects using Inspektor Gadget: 78 79 - Update the [Azure Kubernetes Service (AKS) Extension for Visual Studio Code](https://github.com/Azure/vscode-aks-tools/pull/191). 80 81 ## Troubleshooting a failed release 82 83 ### The CI process for the tag failed 84 85 It can happen that the CI fails because of a flaky test, it's fine to rerun the failed jobs to make 86 them pass. 87 88 ### The krew-index PR wasn't merged automatically 89 90 In some situations the PR is not merged by the bot, in that case it's necessary to ping the 91 Krew maintainers to manually merge it. 92 93 94 ## Release cadence 95 96 We try to make a new release the first Monday of each month, however we can delay it a bit if there 97 are issues that need to be handled before. 98 99 If there is a security issue or an important bug fix we make patch releases in between. We don't 100 have a formal definition of what an "important bug fix" is, it's up the team to discuss and decide 101 whether to make a new release or not. 102 103 ## Making a bugfix release 104 105 All newly merged patches fixing previous bug have to be backported to the latest release. 106 When you merge a PR containing a patch fixing a bug, you should test if the buggy commits belongs to the latest release. 107 Let's take an example with this commit: 108 109 ```patch 110 commit 95fe7405738d58476ddad29856ebe30599644666 111 Author: author <author@mail.com> 112 Date: Tue Jan 9 16:42:38 2024 +0100 113 114 check for empty record in capabilities tracer to avoid a panic 115 116 Fixes: 39aefb92dd1df2ff73647b17707984662f8718c0 ("pkg/gadgets: Add capabilities CO-RE tracer.") 117 Signed-off-by: author <author@mail.com> 118 ``` 119 120 To test if the buggy commit belongs to the latest release, you can use the following: 121 122 ```bash 123 $ git tag --contains 39aefb92dd1df2ff73647b17707984662f8718c0 --sort=-v:refname 124 v0.x.y 125 ... 126 v0.x.1 127 v0.x.0 128 v0.24.0 129 v0.23.1 130 ``` 131 132 You now need to backport the patch to the latest release branch: 133 134 ```bash 135 $ git checkout release-v0.x 136 $ git pull 137 $ git checkout -b release-v0.x/fix-something 138 $ git cherry-pick 95fe7405738d58476ddad29856ebe30599644666 139 # If the patch does not apply cleanly, you will need to adapt it. 140 # Once done, push your branch and open a PR against the release branch: 141 $ git push --set-upstream origin release-v0.x/fix-something 142 ``` 143 144 Even if the patch applies cleanly, you need to open a PR. 145 Once your PR is merged, you can now create the bugfix tag: 146 147 ```bash 148 $ git checkout release-v0.x 149 $ git pull 150 # Where z would be y + 1: 151 $ git tag v0.x.z 152 ``` 153 154 Once done, follow the instructions listed [here](#making-a-new-release), to create a new release.