User:Nex/Maintainer-Notes/Version bump and stabilization workflow

This is my workflow when adding new versions and how to start the stabilization process. If anything on this page is incorrect or can be improved, please let me know in the discussion so I can adjust my workflow accordingly. Minor mistakes (e.g. spelling) can always be improved without asking, of course.

Getting updates on new versions
To receive updates about new versions, go to the upstream page (usually GitHub, GitLab, etc.) and enable custom notifications for releases. To receive notifications for serious issues, notifications for issues should be enabled as well.

New versions
When a new release is published upstream, check out the new version of the repo locally an diff against the old version to check for notable changes which might affect dependencies and/or the the commands in the ebuild.

Copy the old ebuild (or the live ebuild template) to the new version, optionally adjust the ebuild to account for aforementioned notable changes. If necessary, adjust the live ebuild before copying so both ebuilds receive the update. Dont forget to remove stable keywords for the new ebuild:

If EAPI should be bumped to the highest possible version if it isn't already. In case the EAPI gets bumped, EAPI Usage and Description should be consulted to check for important changes which are necessary for the ebuild to work (e.g. new or deprecated/banned DEPEND variables). Now the ebuild needs to be compiled and tested. If everything works as expected, the changes can be commited and a PR can be opened for ::gentoo.

Stabilization reminder
The new version shall be stabilized according to the devmanual. To set up a TODO item in Taskwarrior, run

Where X is the day where the stabilization shall happen. Wait is set so that the task isn't show before it's actually important to think about stabilization (i.e. a few days before it can be stabilized). To highlight the task on the day where the stablereq shall happen.

Stabilization requests
Before starting the stablereq, make sure the package works as expected. Check if any important issues have been opened for this version. This usually means checking the email inbox for any notifications from the respective software forge and can be done continuously and the stabilization task should not be added to Taskwarrior, if serious issues were spotted).

If a versions is considered suitable for a stablereq, use to generate the package list for the stablereq bug:

Note that must be executed in a directory with the ebuild repo checked out, since it inspects the ebuilds to make the package list.

Finally, file a bug in the Stabilization component with the following metadata:


 * Summary: cat/pkg-ver: stablereq
 * Description: Be creative. The content doesn't really matter.

Create the bug and edit the remaining metadata. For some reason this metadata can't be entered when filing the bug:


 * Package List: Take the filtered and checked output from
 * Keywords:

The stablereq is now filed and there is nothing left to do. Don't forget to mark the stablereq task as done in the task manager.