#298 Various enhancements to the docs
Merged a year ago by nphilipp. Opened a year ago by zbyszek.
fedora-infra/ zbyszek/rpmautospec doc-cleanup  into  main

file modified
+5
@@ -1,6 +1,11 @@ 

  Python Package for Automatic Generation of RPM Release Fields and Changelogs

  ============================================================================

  

+ .. note::

+ 

+    Documentation is available at

+    https://docs.pagure.org/fedora-infra.rpmautospec/index.html

+ 

  This project hosts the ``rpmautospec`` python package and script, which has these functions:

  

  - Attempt to automatically calculate release numbers and generate an RPM changelog from the dist-git

file modified
+6 -8
@@ -1,7 +1,7 @@ 

  .. _using-autochangelog:

  

- Using the ``%autochangelog`` Macro

- ==================================

+ The ``%autochangelog`` Macro

+ ============================

  

  `rpmautospec` combines two sources of information to generate a changelog

  which is inserted in the spec file where the ``%autochangelog`` macro is set.
@@ -87,13 +87,11 @@ 

  still bumped for such commits.

  

  

- Examples

- --------

  

  .. _only commits example:

  

- Only Commits

- ^^^^^^^^^^^^

+ Example: Only Commits

+ ^^^^^^^^^^^^^^^^^^^^^

  

  If a package has no ``changelog`` file, `rpmautospec` will only use the git

  history to generate the changelog.
@@ -138,8 +136,8 @@ 

  

  .. _commits and changelog example:

  

- Commits and Changelog

- ^^^^^^^^^^^^^^^^^^^^^

+ Example: Commits and Changelog

+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  

  If a package has a ``changelog`` file, `rpmautospec` will only generate entries

  from the commits after its last change and then append its contents verbatim.

file modified
+18 -20
@@ -1,7 +1,11 @@ 

  .. _using-autorelease:

  

- Using the ``%autorelease`` Macro

- ================================

+ **************************

+ The ``%autorelease`` Macro

+ **************************

+ 

+ The contents of the ``Release`` field

+ =====================================

  

  Fedora's `Versioning Guidelines`_ define the different elements of which a

  release field consists. They are as follows:
@@ -23,7 +27,6 @@ 

    the option when bumping the version the next time).

  * ``-n``: Don’t render the dist tag, e.g. for use in macros, if the dist tag is added later.

  

- 

  .. important::

      To date, the ``%autorelease`` parameters are ignored in the headers of automatically generated

      changelog entries.
@@ -32,13 +35,11 @@ 

      In the prototype version the macro was named ``%autorel``. To make its purpose more obvious, it is

      ``%autorelease`` now.

  

- Examples

- --------

  

  .. _simple example:

  

- The Simple Case

- ^^^^^^^^^^^^^^^

+ Example: The Simple Case

+ ^^^^^^^^^^^^^^^^^^^^^^^^

  

  .. literalinclude:: examples/test-autorelease.spec

     :language: spec
@@ -50,8 +51,8 @@ 

  

  .. _baserelease example:

  

- The Custom Base Release Case

- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

+ Example: The Custom Base Release Case

+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  

  .. literalinclude:: examples/test-autorelease-baserelease.spec

     :language: spec
@@ -88,13 +89,10 @@ 

  

  In the modern versioning, those fields are embedded in the package `Version` instead.

  

- Examples

- --------

- 

  .. _prerelease example:

  

- The Pre-Release Case

- ^^^^^^^^^^^^^^^^^^^^

+ Example: The Pre-Release Case

+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  

  .. literalinclude:: examples/test-autorelease-prerelease.spec

     :language: spec
@@ -106,8 +104,8 @@ 

  

  .. _extraver case:

  

- The Extraver Case

- ^^^^^^^^^^^^^^^^^

+ Example: The Extraver Case

+ ^^^^^^^^^^^^^^^^^^^^^^^^^^

  

  .. literalinclude:: examples/test-autorelease-extraver.spec

     :language: spec
@@ -119,8 +117,8 @@ 

  

  .. _snapshot case:

  

- The Snapshot Case

- ^^^^^^^^^^^^^^^^^

+ Example: The Snapshot Case

+ ^^^^^^^^^^^^^^^^^^^^^^^^^^

  

  .. literalinclude:: examples/test-autorelease-snapshot.spec

     :language: spec
@@ -132,8 +130,8 @@ 

  

  .. _snapshot_and_extraver case:

  

- The Snapshot and Extraver case

- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

+ Example: The Snapshot and Extraver case

+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  

  .. literalinclude:: examples/test-autorelease-extraver-snapshot.spec

     :language: spec

file modified
+2 -11
@@ -1,5 +1,5 @@ 

- Welcome to the documentation of `rpmautospec`!

- ==============================================

+ Automatically populate RPM release and changelog fields

+ =======================================================

  

  `rpmautospec` is a program and library used to automatically generate the

  release and changelog fields in RPM spec files opting to use it.
@@ -15,12 +15,3 @@ 

     autochangelog

     peculiarities

     install

- 

- 

- 

- Indices and tables

- ------------------

- 

- * :ref:`genindex`

- * :ref:`modindex`

- * :ref:`search`

file modified
+4 -3
@@ -1,5 +1,6 @@ 

+ ************************

  Installing `rpmautospec`

- ========================

+ ************************

  

  `rpmautospec` consists of these components:

  
@@ -22,8 +23,8 @@ 

      The library requires a minimum Python version of 3.6.

  

  

- Installing the Koji Builders Plugin

- -----------------------------------

+ Installing the Koji Builder Plugin

+ ----------------------------------

  

  The Koji plugin ``rpmautospec_builder`` is meant to be installed on all the

  Koji builders running the ``buildSRPMFromSCM`` task in:

file modified
+16 -17
@@ -1,13 +1,13 @@ 

- Opting into using `rpmautospec`

- ===============================

+ *******************

+ Using `rpmautospec`

+ *******************

  

- To opt into using `rpmautospec` you need to use the two macros as explained

- here below:

+ To use `rpmautospec` you need to employ the two macros described below.

  

- Use the ``%autorelease`` macro

- ------------------------------

+ Using the ``%autorelease`` macro

+ --------------------------------

  

- Basically, in the spec file you replace the manually set release, e.g.:

+ Basically, in the spec file you replace the manually-set release, e.g.:

  

  .. code-block:: spec

  
@@ -30,8 +30,8 @@ 

      documented here: :ref:`using-autorelease`.

  

  

- Use the ``%autochangelog`` macro

- --------------------------------

+ Using the ``%autochangelog`` macro

+ ----------------------------------

  

  For new packages

  ^^^^^^^^^^^^^^^^
@@ -59,9 +59,9 @@ 

  

  Use the ``convert`` command to do this automatically:

  

- ::

+ .. code-block:: console

  

-     rpmautospec convert

+     $ rpmautospec convert

  

  

  After the change, the content of the ``%changelog`` section should be:
@@ -75,10 +75,9 @@ 

  history of your git repository up until the most recent commit that

  changes the ``changelog`` file.

  

- More explanations on how the ``%autochangelog`` macro works can be found

- in :ref:`using-autochangelog`.

- 

- 

  .. note::

-     Congratulations for opting into `rpmautospec`. You may now want to have a

-     look at the :ref:`peculiarities`.

+ 

+   More details about how to write multi-line entries or skip commits

+   in the changelog can be found in :ref:`using-autochangelog`.

+   More information about limitations of `rpmautospec` and

+   solutions to some common issues are described in the :ref:`peculiarities`.

file modified
+14 -11
@@ -1,7 +1,8 @@ 

  .. _peculiarities:

  

+ ******************************

  Peculiarities of `rpmautospec`

- ==============================

+ ******************************

  

  `rpmautospec` has few peculiarities that we are aware of. Some may get

  fixed, others are considered negligible, but we still want to document them
@@ -53,23 +54,25 @@ 

  as the merge commit and disregard the others.

  

  

- Rebuilding a package without changing it

- ----------------------------------------

+ Rebuilding a package with no changes

+ ------------------------------------

  

- In the past, rebuilding a package to pick up changed dependencies, or in the context of mass

- rebuilds was accomplished by bumping the release and adding a suitable changelog entry. With

- `rpmautospec`, you have to tell git that you really want to add a commit without any changes in

- content to accomplish the equivalent, e.g.:

+ In the past, rebuilding a package to pick up changed dependencies or

+ in the context of mass rebuilds was accomplished by bumping the

+ release and adding a suitable changelog entry and creating a commit.

+ With `rpmautospec`, we only need the last step.

+ But you have to tell git that you really want to add a

+ commit without any changes:

  

  .. code-block:: bash

  

-     git commit --allow-empty

+     git commit --allow-empty -m 'Rebuild for …'

  

- The resulting empty head commit can be pushed into the repository of the package and built normally.

+ The resulting empty commit can be pushed into the repository of the package and built normally.

  

  

- Information about rpmautospec use in a built package

- ----------------------------------------------------

+ Information about `rpmautospec` use in a built package

+ ------------------------------------------------------

  

  When preprocessing spec files for building, `rpmautospec` adds a header to the

  top of the spec file containing, among other things, information about its

I started working on this a while ago, but for some reason I forgot to submit a PR.
More changes are certainly needed, but I think that each of those changes is reasonable
on its own, so I'm pushing that now get the ball rolling.

Looks good to me, thanks!

Pull-Request has been merged by nphilipp

a year ago