Fedora Release Process


Prerequisites

DS = 389-ds-base source code repo

mkdir -p /home/$USER/source/ds389; cd /home/$USER/source/ds389
git clone git@github.com:389ds/389-ds-base.git

Fedora = 389-ds-base dist-git repo which contains the specfile

mkdir -p /home/$USER/source/fedora; cd /home/$USER/source/fedora
fedpkg clone 389-ds-base

DS - Using an existing branch

Fedora - Dist-Git - New release

In general, when we do a new build, we push changes to rawhide first, so that the development branch has the newest bits, then to active Fedora releases ( f39, f40)

Fedora - Dist-Git Option 2 - Test build with patches

Let assume rawhide branch contains some fixes that are partial (or broken) and you want to do a rawhide build with a crafted list of patches

DS - Push the updates and the tag

NOTE: Do not push the tags until you are sure the builds were successful! Once you push a tag, you cannot change it - if you need to make a change to fix a build problem, you will essentially have to repeat all of the steps again, since this will involve a new source version.

NOTE: Do not git push --tags - you may inadvertently push tags you did not intend - push tags specifically by name

    cd /home/source/ds389/ds
    git push origin 389-ds-base-2.2
    git push origin refs/tags/389-ds-base-2.2.2

Update The Wiki (internal use only)

I found ghostwriter useful for displayig the markdown file changes.

Last modified on 1 March 2024