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

From Gentoo Wiki
Jump to:navigation Jump to:search

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 ekeyword to remove stable keywords for the new ebuild:

user $ekeyword '~all' the-new.ebuild
Note
Since the ~ character is usually interpreted by the shell, putting ~all in quotes is important.

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.

user $git add .
user $pkgdev commit -s


Note
Currently, pkgdev does not automatically alter the copyright year when commiting an ebuild. This must be done manually before committing.

Stabilization reminder

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

user $task add project:Gentoo wait:X-2 scheduled:X due:X+2 priority:M cat/pkg-ver: stablereq
user $task sync

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 app-portage/nattka to generate the package list for the stablereq bug:

user $nattka make-package-list -s cat/pkg-ver

Note that nattka 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 nattka
  • Keywords: CC-ARCHES


Note
nattka handles CC'ing arches in the stablereq automatically.

To make sure the CCs are correct,

always set the CC-ARCHES keyword instead of CC'ing arches manually.

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.

See Also

Retrieved from "https://wiki.gentoo.org/index.php?title=User:Nex/Maintainer-Notes/Version_bump_and_stabilization_workflow&oldid=1124803"