#30 Automate updating Fedora version in docs
Merged 2 years ago by ankursinha. Opened 2 years ago by oturpe.
fedora-docs/ oturpe/package-maintainer-docs os-version-attribute  into  master

Automate updating Fedora version in docs
Otto Urpelainen • 2 years ago  
@@ -1,3 +1,5 @@ 

+ include::{partialsdir}/attributes.adoc[]

+ 

  = New Package Process for New Contributors

  :toc:

  
@@ -142,8 +144,9 @@ 

  To request branches for other Fedora releases,

  use `fedpkg request-branch`:

  

+ [subs="attributes+"]

  ....   

- fedpkg request-branch --repo python-prometheus_client f34

+ fedpkg request-branch --repo python-prometheus_client f{MAJOROSVER}

  ....

  

  You will need to run this for each non-rawhide branch.
@@ -236,7 +239,7 @@ 

  fedpkg switch-branch BRANCH 

  ....

  

- (e.g. `f34`)

+ (e.g. `f{MAJOROSVER}`)

  

  Merge the initial commit from main (Rawhide),

  creating an identical commit in the branch:

@@ -1,3 +1,5 @@ 

+ include::{partialsdir}/attributes.adoc[]

+ 

  = Package Maintenance Guide

  :toc:

  
@@ -179,8 +181,9 @@ 

  Do remember not to leave stale sources lying around.

  

  === Switch to a different release branch

+ [subs="attributes+"]

  ....

- fedpkg switch-branch <f34,el6,rawhide>

+ fedpkg switch-branch <f{MAJOROSVER},el{MAJOREPELVER},rawhide>

  ....

  

  Each Fedora release has its own branch in each package repository
@@ -319,9 +322,10 @@ 

  Each Fedora release is represented by a branch in the git repository.

  You can switch between them like this:

  

+ [subs="attributes+"]

  ....

- fedpkg switch-branch f34

- fedpkg switch-branch f33

+ fedpkg switch-branch f{MAJOROSVER}

+ fedpkg switch-branch f{PREVIOUSOSVER}

  fedpkg switch-branch rawhide

  ....

  
@@ -332,19 +336,20 @@ 

  However, git provides us with several handy tools for working with branches.

  Here's an example:

  

+ [subs="attributes+"]

  ....

  fedpkg clone bzrtools

  # Make some changes in the rawhide branch

  fedpkg new-sources bzrtools-2.2.tar.gz

  gedit bzrtools.spec

  fedpkg commit

- fedpkg switch-branch f34

+ fedpkg switch-branch f{MAJOROSVER}

  git merge rawhide

  # for push into repo

  fedpkg push

  ....

  

- This will _merge_ the changes from the `rawhide` branch to the `f34` branch.

+ This will _merge_ the changes from the `rawhide` branch to the `f{MAJOROSVER}` branch.

  Git aficionados may note this is a somewhat unusual workflow,

  but it is appropriate to the context of package management.

  Remember,
@@ -358,17 +363,18 @@ 

  so long as the branches have not previously diverged.

  That is, if you do this:

  

+ [subs="attributes+"]

  ....

  fedpkg clone bzrtools

  # Make some changes in the rawhide branch

  fedpkg commit

- fedpkg switch-branch f34

- # Make some changes in the f34 branch

+ fedpkg switch-branch f{MAJOROSVER}

+ # Make some changes in the f{MAJOROSVER} branch

  fedpkg commit

  fedpkg switch-branch rawhide

  # Make some more changes in the rawhide branch

  fedpkg commit

- fedpkg switch-branch f34

+ fedpkg switch-branch f{MAJOROSVER}

  git merge rawhide

  ....

  
@@ -520,7 +526,7 @@ 

  === Making changes on an older branch without breaking the upgrade path

  

  Here is the scenario:

- You have built your package successfully on the `f34` branch,

+ You have built your package successfully on the `f{MAJOROSVER}` branch,

  but there is a problem keeping your package from building on `last`.

  

  Solution:

@@ -1,3 +1,5 @@ 

+ include::{partialsdir}/attributes.adoc[]

+ 

  = Package Review Process

  :toc:

  
@@ -128,9 +130,9 @@ 

  

  * If you want to add your package to more Fedora releases

  and not just Rawhide,

- let's say to Fedora 34,

+ let's say to Fedora {MAJOROSVER},

  you can use the following command to request additional branches:

- `fedpkg request-branch --repo f34`.

+ `fedpkg request-branch --repo f{MAJOROSVER}`.

  You must wait for your repository to be created

  before filing your branch request,

  otherwise your branch request will be closed as invalid.
@@ -149,7 +151,7 @@ 

  (You will need to set up https://fedoraproject.org/wiki/Infrastructure/Kerberos[Kerberos for Fedora project])

  

  * Repeat the process for other branches you may have requested above:

- ** Checkout given branch: `fedpkg switch-branch f34`

+ ** Checkout given branch: `fedpkg switch-branch f{MAJOROSVER}`

  ** Let Koji build the package for this branch: `fedpkg build`

  

  * Request updates for Fedora release branches, if necessary,

@@ -1,3 +1,5 @@ 

+ include::{partialsdir}/attributes.adoc[]

+ 

  = Package Update Guide

  :toc:

  
@@ -97,26 +99,28 @@ 

  Alternatively, you can specify the parent/base tag

  from which to create the side-tag, e.g.:

  

+ [subs="attributes+"]

  ....

- fedpkg request-side-tag --base-tag f32-build

+ fedpkg request-side-tag --base-tag f{MAJOROSVER}-build

  ....

  

  

  NOTE: Side-tags for particular Fedora releases are based off its respective build tag.

  I.e. if you wanted to create a side-tag for Rawhide

- while it's ramping up for Fedora 32,

- the parent tag to choose would be `f32-build`.

+ while it's ramping up for Fedora {MAJOROSVER},

+ the parent tag to choose would be `f{MAJOROSVER}-build`.

  

  This will tell you the commands to

  

  . build a package in the specific side-tag and

  . wait for the respective build root to be recreated, e.g.:

  

+ [subs="attributes+"]

  ....

- $ fedpkg request-side-tag --base-tag f32-build

- Side tag 'f32-build-side-7863' (id 7863) created.

- Use 'fedpkg build --target=f32-build-side-7863' to use it.

- Use 'koji wait-repo f32-build-side-7863' to wait for the build repo to be generated.

+ $ fedpkg request-side-tag --base-tag f{MAJOROSVER}-build

+ Side tag 'f{MAJOROSVER}-build-side-7863' (id 7863) created.

+ Use 'fedpkg build --target=f{MAJORSOVER}-build-side-7863' to use it.

+ Use 'koji wait-repo f{MAJOROSVER}-build-side-7863' to wait for the build repo to be generated.

  ....

  

  The latter is important
@@ -357,8 +361,9 @@ 

  that will let you monitor when the package appears in the buildroot,

  so you can fire your dependent build at the appropriate time:

  

+ [subs="attributes+"]

  ....

- koji wait-repo f34-build --build=(name-version-release)

+ koji wait-repo f{MAJOROSVER}-build --build=(name-version-release)

  ....

  

  You can also request buildroot overrides from the https://bodhi.fedoraproject.org/overrides/new[Bodhi web application].

@@ -1,1 +1,4 @@ 

  :year: 2021

+ :MAJOROSVER: 34

+ :PREVIOUSOSVER: 33

+ :MAJOREPELVER: 8

In many places, a Fedora version number is used as and example,
in strings like Fedora 34, f34, fc34.
The docs read better if the version is always the current release,
or perhaps one behind.

AsciiDoc attributes are used to define
the current and previous OS version
as well as the current EPEL version
in one place.
The attributes are then referred to
in all examples that need those values.

rebased onto b703e28014230b10a0ca58179c6ac8d3e4b58e1e

2 years ago

rebased onto 5344421

2 years ago

Metadata Update from @ankursinha:
- Request assigned

2 years ago

Looks good, tested locally. No issues. Merging.

Pull-Request has been merged by ankursinha

2 years ago

Thank you for the review!
There actually one misspelling,
local preview warned about that:

asciidoctor: WARNING: skipping reference to missing attribute: majorsover

I fixed this in commit 49818fd.