3 files changed, 28 insertions, 69 deletions

diff --git a/doc/NEW_STARTERS b/doc/NEW_STARTERS
index 2c5aac88..4fda35fb 100644
--- a/doc/NEW_STARTERS
+++ b/doc/NEW_STARTERS
@@ -10,7 +10,7 @@ Need to know:
 
 1. Add member to team mailing list (https://www.monitoring-plugins.org/list/listinfo/team/)
    and to the commits mailing list (https://www.monitoring-plugins.org/list/listinfo/commits/),
-   add sourceforge email address via Privacy Options->Sender filters)
+   add sourceforge email address via Privacy Options->Sender filters
 2. Add Sourceforge access:
   - Translator: CVS access, Shell access, Release Tech (no)
   - Developer: Project role: Developer, CVS access, Shell access, Release Tech (no), Task Manager (A&T),
diff --git a/doc/RELEASING.md b/doc/RELEASING.md
index f0932bd4..700683e7 100644
--- a/doc/RELEASING.md
+++ b/doc/RELEASING.md
@@ -2,23 +2,23 @@ Releasing a New Monitoring Plugins Version
 ==========================================
 
 Throughout this document, it is assumed that the current Monitoring
-Plugins version is 2.3.4, and that we're about to publish version 2.4.
+Plugins version is 2.4.0, and that we're about to publish version 2.5.
 It is also assumed that the official repository on GitHub is tracked
 using the remote name `monitoring-plugins` (rather than `origin`).
 
 Before you start
 ----------------
 
-- Check Github Actions status.
+- Check GitHub Actions status.
 - Update local Git repository to the current `master` tip.  For a
-  maintenance release (e.g., version 2.3.4), update to the current
-  `maint-2.3` tip, instead.
+  maintenance release (e.g., version 2.4.1), update to the current
+  `maint-2.4` tip, instead.
 
 Prepare and commit files
 ------------------------
 
 - Update `configure.ac` and `NP-VERSION-GEN` with new version.
-- Update `NEWS` from `git log --reverse v2.3.4..` output, and specify
+- Update `NEWS` from `git log --reverse v2.4.0..` output, and specify
   the release version/date.
 - Update `AUTHORS` if there are new team members.
 - Update `THANKS.in` using `tools/update-thanks`.
@@ -29,27 +29,27 @@ Prepare and commit files
 Create annotated tag
 --------------------
 
-    git tag -a -m 'Monitoring Plugins 2.4' v2.4
+    git tag -a -m 'Monitoring Plugins 2.5' v2.5
 
 Push the code and tag to GitHub
 -------------------------------
 
     git push monitoring-plugins master
-    git push monitoring-plugins v2.4
+    git push monitoring-plugins v2.5
 
 Create new maintenance branch
 -----------------------------
 
 _Only necessary when creating a feature release._
 
-    git checkout -b maint-2.4 v2.4
-    git push -u monitoring-plugins maint-2.4
+    git checkout -b maint-2.5 v2.5
+    git push -u monitoring-plugins maint-2.5
 
 Checkout new version
 --------------------
 
     rm -rf /tmp/plugins
-    git archive --prefix=tmp/plugins/ v2.4 | (cd /; tar -xf -)
+    git archive --prefix=tmp/plugins/ v2.5 | (cd /; tar -xf -)
 
 Build the tarball
 -----------------
@@ -62,26 +62,26 @@ Build the tarball
 Upload tarball to web site
 --------------------------
 
-    scp monitoring-plugins-2.4.tar.gz \
+    scp monitoring-plugins-2.5.tar.gz \
         plugins@orwell.monitoring-plugins.org:web/download/
 
 Generate SHA1 checksum file on web site
 ---------------------------------------
 
     ssh plugins@orwell.monitoring-plugins.org \
-        '(cd web/download; $HOME/bin/create-checksum monitoring-plugins-2.4.tar.gz)'
+        '(cd web/download; $HOME/bin/create-checksum monitoring-plugins-2.5.tar.gz)'
 
 Announce new release
 --------------------
 
 - In the site.git repository:
 
-    - Create `web/input/news/release-2-4.md`.
+    - Create `web/input/news/release-2.5.md`.
     - Update the `plugins_release` version in `web/macros.py`.
     - Commit and push the result:
 
-            git add web/input/news/release-2-4.md
-            git commit web/input/news/release-2-4.md web/macros.py
+            git add web/input/news/release-2.5.md
+            git commit web/input/news/release-2.5.md web/macros.py
             git push origin master
 
 - Post an announcement on (at least) the following mailing lists:
@@ -93,6 +93,6 @@ Announce new release
 
 If you want to mention the number of contributors in the announcement:
 
-    git shortlog -s v2.3.4..v2.4 | wc -l
+    git shortlog -s v2.4.0..v2.5 | wc -l
 
 <!-- vim:set filetype=markdown textwidth=72: -->
diff --git a/doc/developer-guidelines.sgml b/doc/developer-guidelines.sgml
index 37c963ed..8288b897 100644
--- a/doc/developer-guidelines.sgml
+++ b/doc/developer-guidelines.sgml
@@ -14,15 +14,8 @@
     <pubdate>2013</pubdate>
     <title>Monitoring Plugins Development Guidelines</title>
 
-    <revhistory>
-       <revision>
-          <revnumber>1796</revnumber>
-          <date>2007-09-24 14:51:07 -0400 (Mon, 24 Sep 2007)</date>
-       </revision>
-    </revhistory>
-
         <copyright>
-                <year>2000 - 2013</year>
+                <year>2000 - 2024</year>
                 <holder>Monitoring Plugins Development Team</holder>
         </copyright>
 
@@ -30,11 +23,11 @@
 
 
 <preface id="preface"><title>Preface</title>
-    <para>The purpose of this guidelines is to provide a reference for
+    <para>The purpose of these guidelines is to provide a reference for
     the plugin developers and encourage the standardization of the
-    different kind of plugins: C, shell, perl, python, etc.</para>
+    different kinds of plugins: C, shell, perl, python, etc.</para>
 
-        <para>Monitoring Plugins Development Guidelines Copyright (C) 2000-2013
+        <para>Monitoring Plugins Development Guidelines Copyright (C) 2000-2024
         (Monitoring Plugins Team)</para>
 
         <para>Permission is granted to make and distribute verbatim
@@ -75,7 +68,7 @@
 
                 <para>You should always print something to STDOUT that tells if the
                 service is working or why it is failing. Try to keep the output short -
-                probably less that 80 characters. Remember that you ideally would like
+                probably less than 80 characters. Remember that you ideally would like
                 the entire output to appear in a pager message, which will get chopped
                 off after a certain length.</para>
 
@@ -221,7 +214,7 @@
                 back a numerical value, or metric, which is then compared to the warning and
                 critical thresholds. Use the get_status(double, thresholds *) function to
                 compare the value against the thresholds.</para>
-                <para>This is the generalised format for ranges:</para>
+                <para>This is the generalized format for ranges:</para>
 
                 <literallayout>
                 [@]start:end
@@ -383,13 +376,6 @@
                 <para>It is up to third party programs to convert the Monitoring Plugins
                 performance data into graphs.</para>
                 </section>
-
-        <section><title>Translations</title>
-        <para>If possible, use translation tools for all output to respect the user's language
-                settings. See <xref linkend="translationsdevelopers"> for guidelines
-                for the core plugins.
-        </para>
-        </section>
 </section>
 
 <section id="SysCmdAuxFiles"><title>System Commands and Auxiliary Files</title>
@@ -488,7 +474,7 @@
                         </listitem>
 
                         <listitem><para>If writing to a file (perhaps recording
-                        performance data) explicitly close close it.  The plugin never
+                        performance data) explicitly close it.  The plugin never
                         calls <emphasis role="strong">exit</emphasis>; that is caught by
                         p1.pl, so output streams are never closed.</para>
                         </listitem>
@@ -727,19 +713,18 @@ setup the tests. Run "make test" to run all the tests.
 </section>
 <section id="CodingGuidelines"><title>Coding guidelines</title>
         <para>See <ulink url="http://www.gnu.org/prep/standards_toc.html">GNU
-        Coding standards</ulink> for general guidelines.</para>
+        Coding standards</ulink> for general guidelines.
+        Some parts of the guidelines (namely and explicitly the coding style)
+        are not seen as best practice by us.</para>
         <section><title>C coding</title>
 
-        <para>Variables should be declared at the beginning of code blocks and
-        not inline because of portability with older compilers.</para>
-
         <para>You should use the type "bool" and its values
         "true" and "false" instead of the "int" type for booleans.
         </para>
         </section>
 
         <section><title>Crediting sources</title>
-        <para>If you have copied a routine from another source, make sure the licence
+        <para>If you have copied a routine from another source, make sure the license
         from your source allows this. Add a comment referencing the ACKNOWLEDGEMENTS
         file, where you can put more detail about the source.</para>
         <para>For contributed code, do not add any named credits in the source code
@@ -756,32 +741,6 @@ setup the tests. Run "make test" to run all the tests.
         <para>All commits will be written to a ChangeLog at release time.
         </para>
         </section>
-
-        <section id="translationsdevelopers"><title>Translations for developers</title>
-        <para>To make the job easier for translators, please follow these guidelines:</para>
-        <orderedlist>
-          <listitem><para>
-            Before creating new strings, check the po/monitoring-plugins.pot file to
-            see if a similar string
-            already exists
-          </para></listitem>
-          <listitem><para>
-            For help texts, break into individual options so that these can be reused
-            between plugins
-          </para></listitem>
-          <listitem><para>Try to avoid linefeeds unless you are working on a block of text</para></listitem>
-          <listitem><para>Short help is not translated</para></listitem>
-          <listitem><para>Long help has options in English language, but text translated</para></listitem>
-          <listitem><para>"Copyright" kept in English</para></listitem>
-          <listitem><para>Copyright holder names kept in original text</para></listitem>
-          <listitem><para>Debugging output does not need to be translated</para></listitem>
-        </orderedlist>
-        </section>
-
-        <section><title>Translations for translators</title>
-        <para>To create an up to date list of translatable strings, run: tools/gen_locale.sh</para>
-        </section>
-
 </section>
 
 <section id="SubmittingChanges"><title>Submission of new plugins and patches</title>