Skip to content

Improve release instructions #647

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
68 changes: 59 additions & 9 deletions docs/create-new-invidious-release.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,12 +19,12 @@ git remote update
git pull origin master
```


## Step 1

Update CHANGELOG.md to reflect the changes made since the last release.
* Update version in `shard.yml`.
* Update `CHANGELOG.md` to reflect the changes made since the last release.

Each changelog entry is composed of a summary and a list of PRs (~= diff).
Each changelog entry is composed of a summary and a list of PRs.

The summary should be simple and concise, and only reflect most important
changes, preferably sorted by impact (new features/breaking changes that the
Expand All @@ -34,13 +34,14 @@ last). Minor changes that are related to repo maintenance can be ignored.
Do not forget to list **ALL** the PRs that have been merged since the last
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do you think we should document the stray commits that occasionally get pushed without an associated PR?

Copy link
Member

@syeopite syeopite May 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's somewhat of a convention in how each PR is listed so maybe we could document that?

Here's how I understand it at least:

Suggested change
Do not forget to list **ALL** the PRs that have been merged since the last
Do not forget to list **ALL** the PRs that have been merged since the last
release, with the proper links.
The pull requests should be listed from the most recently merged to the oldest. Each entry should roughly follow this template:
`{Summary} (#{PR Number}, by/thanks @{Author})`
If the pull request is by a core team member they should be attributed with `by @{Author}`
Otherwise the PR author should be attributed with `thanks @{Author}`

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do you think we should document the stray commits that occasionally get pushed without an associated PR?

Hmm, that's a good question. For "revert" commits, I think we can simply remove the associated PR from the list, or at least mark it as (reverted). For the rest I don't know. That's the reason why I'd like to enfore the "always make PRs" policy, and keep stray commits to fix bugs/typos in a recently merged PR.

There's somewhat of a convention in how each PR is listed so maybe we could document that?

Yeah, That's a good idea!

Here's how I understand it

That's it, except that I used the PR title, rather than a summary. I often had to reword PRs on github to make the title more meaningful than fix bug #123...

release, with the proper links.

Note: Maybe this should be done each time a PR is marged?
Note: Maybe this should be done each time a PR is merged?


## Step 2

Commit the changes made to `CHANGELOG.md`:
Commit the changes made in step 1:
```sh
git add CHANGELOG.md shard.yml
git commit -S -m "Release vX.Y.Z"
```

Expand All @@ -49,21 +50,70 @@ git commit -S -m "Release vX.Y.Z"
git tag -as vX.Y.Z
```

Git will ask to provide a tag message. All you have to do is copy/pasting the
summary from `CHANGEMLOG.md` and adapt a the formatting as required. Do not
Git will ask to provide a tag annotation. All you have to do is copy/pasting
the summary from `CHANGELOG.md` and adapt the formatting as required. Do not
include the list of PRs merged.

??? warning Amending your release commit

If for some reason you need to amend your release commit (e.g you made a typo
in the changelog), **make sure to retag afterwards!**

Amending a commit will change its hash, but the tag will remain attached to
the previous (now dangling) commit.

Here's is how to amend your changes and retag:
```sh
# Amend changes
git commit --amend --no-edit

# Retag while reusing the previous tag's annotation
git tag -l --format='%(contents)' vX.Y.Z > tag_msg.tmp
git tag -F tag_msg.tmp -as -f vX.Y.Z
rm tag_msg.tmp
```

Note: **DO NOT** retag if you already pushed you changes. If you made a
mistake (it happens to everybody), just create a new release.


## Step 3

Check that the release commit is properly tagged:
```sh
# Either with git log (colorful, also shows the branches/tags on the remote)
git log --pretty=oneline -3

# Or using git tag (only shows the tag(s) pointing to HEAD)
git tag --points-at HEAD
```

If not, go back to step 2.


## Step 4

Edit `shard.yml` again to add `-dev` to the version string. If you didn't already, also add a "future version" title line to the
top of the changelog under which future PR will be listed.

[Example commit](https://github.com/iv-org/invidious/commit/98926047586154269bb269d01e3e52e60e044035)

Commit your changes:
```
git add CHANGELOG.md shard.yml
git commit -S -m "Prepare for next release"
```

# Step 5

Once you have checked everything, push to GitHub:
```sh
git push origin master
git push upstream vX.Y.Z
git push origin vX.Y.Z
```


## Step 4
## Step 6

Got to GitHub to make a new release:
https://github.com/iv-org/invidious/releases/new
Expand Down