Skip to content
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.

Sign up for GitHub

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

Document new release workflow & add blogpost about it #418

Merged
merged 2 commits into from
Feb 5, 2025
Merged

Document new release workflow & add blogpost about it #418

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
bc2bb7b
Document new release workflow
bastelfreak Feb 4, 2025
8334edc
add blogpost about new release process
bastelfreak Feb 4, 2025
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
52 changes: 31 additions & 21 deletions _docs/releasing_version.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,13 +5,31 @@ date: 2016-01-01
summary: How to perform a complete version release, including modulesync and publication.
---

Creating a release is a two step process:
Creating a release is a three step process:

1. Create a Fork and set the remotes accordingly
2. Prepare the release — setup everything so that peer review can happen and when everything is ready…
1. Create a release PR
2. Review it
3. Do the actual release

## Prepare your Fork
## Preparing a release

Run [modulesync](https://voxpupuli.org/docs/updating-files-managed-with-modulesync/) to ensure the dotfiles are up-to-date.

### As a Vox Pupuli member

To automatically create a "release PR", you need to be a member of the `voxpupuli` GitHub organisation.
Then you can browse to a module -> Actions -> "Prepare Release".
This is a GitHub workflow.
It can automatically:

* bump the metadata.json to the next patchlevel
* Or you provide the desired version number, then metadata.json will be bumped to it
* Afterwards the CHANGELOG.md will be updated
* REFERENCE.md will be updated if required
* A pull request will be created
* GitHub attaches the `skip-changelog` label

### As an outside collaborator

Go to the GitHub project on which you want to generate a new release.
Klick on "fork" and create a local fork.
Expand All @@ -37,12 +55,6 @@ git pull origin master
git push local master
```

## Preparing a release

This should be done on a __*personal*__ fork.

Run modulesync to ensure the dotfiles are up-to-date.

Create a 'release pr'. This pull request updates the changelog and bumps the
version number to the target version, removing all release candidate
identifiers, i.e. from `0.10.7-rc0` to `0.10.7`. Here's an example:
Expand Down Expand Up @@ -83,16 +95,16 @@ We can now generate the changelog after updating the metadata.json with a rake t
CHANGELOG_GITHUB_TOKEN='mytoken' bundle exec rake release:prepare
```

The changelog generator checks for certain labels on closed issues and PRs since
the last release and groups them together. If the changes were neither
backwards-incompatible nor only bug fixes, make a minor release. Check the
generated diff for the CHANGELOG.md. If your chosen release version doesn't
match the generated changelog, update metadata.json and run the changelog task again.
## Reviewing the release PR

The changelog generator checks for certain labels on closed issues and PRs since the last release and groups them together.
If the changes were neither backwards-incompatible nor only bug fixes, make a minor release.
Check the generated diff for the CHANGELOG.md.
If your chosen release version doesn't match the generated changelog, update metadata.json and run the changelog task again.

Get community feedback on the release pr, label it with `skip-changelog`, get it merged.

If a REFERENCE.md is present and outdated, the `release:prepare` task will
regenerate it.
If a REFERENCE.md is present and outdated, the `release:prepare` task will regenerate it.

Now the changes can be committed and pushed.
The rake task will output the commands you need to run.
Expand Down Expand Up @@ -143,7 +155,5 @@ Run the rake target `release`. This will:
bundle exec rake release
```

GitHub Actions (.github/workflows/release.yml in every module) will then kick
off a build against the new tag created and deploy that build to the forge.
*Caution: The Vox Pupuli repo has to be the configured default branch in your
local clone. Otherwise, you will try to release to your fork.*
GitHub Actions (.github/workflows/release.yml in every module) will then kick off a build against the new tag created and deploy that build to the forge.
*Caution: The Vox Pupuli repo has to be the configured default branch in your local clone. Otherwise, you will try to release to your fork.*
22 changes: 22 additions & 0 deletions _posts/2025-02-04-new-release-workflow.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
---
layout: post
title: Vox Pupuli Changelog - New Release process
date: 2024-02-04
github_username: bastelfreak
category: changelog
---

After a lot of work, we've a new GitHub workflow in place.
It can automatically:

* bump the metadata.json to the next patchlevel
* Or you provide the desired version number, then metadata.json will be bumped to it
* Afterwards the CHANGELOG.md will be updated
* REFERENCE.md will be updated if required
* A pull request will be created
* GitHub attaches the `skip-changelog` label

So people don't have to use a local container or Ruby installation to prepare a release.
However, it's still possible to generate everything locally and we intend to keep it that way.

The new workflow is documented at https://voxpupuli.org/docs/releasing_version/