github.com/demonoid81/containerd@v1.3.4/releases/README.md (about)

     1  ## containerd release process
     2  
     3  1. Create release pull request with release notes and updated versions.
     4  
     5     1. Compile release notes detailing features added since the last release and
     6        add release template file to `releases/` directory. The template is defined
     7        by containerd's release tool but refer to previous release files for style
     8        and format help. Name the file using the version, for rc add an `-rc` suffix.
     9        When moving from rc to final, the rc file may just be renamed and updated.
    10        See [release-tool](https://github.com/containerd/project/tree/master/cmd/release-tool)
    11  
    12     2. Update the version file at `https://github.com/containerd/containerd/blob/master/version/version.go`
    13  
    14     3. Update RELEASES.md to refer to the new release and dates.
    15  
    16     4. Update the `.mailmap` files for commit authors which have multiple email addresses in the commit log.
    17        If it is not clear which email or name the contributor might want used in the release notes, reach
    18        out to the contributor for feedback. NOTE: real names should be used whenever possible. The file is
    19        maintained by manually adding entries to the file.
    20        - e.g. `Real Name <preferred@email.com> Other Name <other@email.com>`
    21  
    22     5. Before opening the pull request, run the release tool using the new release notes.
    23        Ensure the output matches what is expected, including contributors, change log,
    24        dependencies, and visual elements such as spacing. If a contributor is duplicated,
    25        use the emails outputted by the release tool to update the mailmap then re-run. The
    26        goal of the release tool is that is generates release notes that need no
    27        alterations after it is generated.
    28  
    29  2. Create tag
    30  
    31     1. Choose tag for the next release, containerd uses semantic versioning and
    32        expects tags to be formatted as `vx.y.z[-rc.n]`.
    33  
    34     2. Generate release notes (using a temp file may be helpful).
    35        - e.g. `release-tool -l -d -n -t v1.0.0 ./releases/v1.0.0.toml > /tmp/v1.0.0-notes`
    36  
    37     3. Create tag using the generated release notes.
    38        - e.g. `git tag --cleanup=whitespace -s v1.0.0 -F /tmp/v1.0.0-notes`
    39  
    40     4. Verify tag (e.g. `git show v1.0.0`), it may help to compare the new tag against previous.
    41  
    42  3. Push tag and Github release
    43  
    44     1. Push the tag to `git@github.com:containerd/containerd.git`.
    45        NOTE: this will kick off CI building of the release binaries.
    46  
    47     2. Create the Github release using the `Tag version` which was just pushed. Use the first
    48        line outputted from the release tool as the `Release title` and the remainder of the
    49        output for the description. No alteration of the release output should be needed.
    50        Ensure `pre-release` is checked if an `-rc`.
    51        NOTE: This should be done immediately after pushing the tag, otherwise CI may create the release
    52        when the binaries are pushed.
    53  
    54     3. Check CI has completed and uploaded the binaries. Remove any binaries which get
    55        uploaded but are not intended as part of the release (e.g. Darwin binaries).
    56  
    57  4. Update [`config.toml`](https://github.com/containerd/containerd.io/blob/f827d53826a426cb48f24cc08e43cc8722ad6d01/config.toml#L35) with latest release in the [containerd/containerd.io project](https://github.com/containerd/containerd.io); open PR to
    58     force website downloads update.
    59  
    60  5. Promote on Slack, Twitter, mailing lists, etc