Change OSSL_DEPRECATED to take a version argument

[openssl.git] / CONTRIBUTING.md

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 0585cf4371fb1463c59b5c600f6ba99d5a9ca8d0..3e11b0b89f61108dba402a5b4c05a616c7206b97 100644 (file)
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -5,7 +5,6 @@ Please visit our [Getting Started][gs] page for other ideas about how to contrib
 
   [gs]: https://www.openssl.org/community/getting-started.html
 
-
 Development is done on GitHub in the [openssl/openssl][gh] repository.
 
   [gh]: https://github.com/openssl/openssl
@@ -30,14 +29,17 @@ guidelines:
     [CLA]: https://www.openssl.org/policies/cla.html
 
     To amend a missing "`CLA: trivial`" line after submission, do the following:
+
     ```
         git commit --amend
         [add the line, save and quit the editor]
         git push -f
     ```
+
  2. All source files should start with the following text (with
     appropriate comment characters at the start of each line and the
     year(s) updated):
+
     ```
         Copyright 20xx-20yy The OpenSSL Project Authors. All Rights Reserved.
 
@@ -52,8 +54,8 @@ guidelines:
     (usually by rebasing) before it will be acceptable.
 
  4. Patches should follow our [coding style][] and compile without warnings.
-    Where gcc or clang is available you should use the
-    --strict-warnings Configure option.  OpenSSL compiles on many varied
+    Where `gcc` or `clang` is available you should use the
+    `--strict-warnings` `Configure` option.  OpenSSL compiles on many varied
     platforms: try to ensure you only use portable features.  Clean builds
     via Travis and AppVeyor are required, and they are started automatically
     whenever a PR is created or updated.
@@ -62,7 +64,7 @@ guidelines:
 
  5. When at all possible, patches should include tests. These can
     either be added to an existing test, or completely new.  Please see
-    test/README for information on the test framework.
+    [test/README.md](test/README.md) for information on the test framework.
 
  6. New features or changed functionality must include
     documentation. Please look at the "pod" files in doc/man[1357] for
@@ -70,18 +72,23 @@ guidelines:
     documentation changes are clean.
 
  7. For user visible changes (API changes, behaviour changes, ...),
-    consider adding a note in [CHANGES](CHANGES).  This could be a summarising
-    description of the change, and could explain the grander details.
+    consider adding a note in [CHANGES.md](CHANGES.md).
+    This could be a summarising description of the change, and could
+    explain the grander details.
     Have a look through existing entries for inspiration.
     Please note that this is NOT simply a copy of git-log one-liners.
-    Also note that security fixes get an entry in CHANGES.
+    Also note that security fixes get an entry in [CHANGES.md](CHANGES.md).
     This file helps users get more in depth information of what comes
     with a specific release without having to sift through the higher
     noise ratio in git-log.
 
  8. For larger or more important user visible changes, as well as
-    security fixes, please add a line in [NEWS](NEWS).  On exception, it might be
-    worth adding a multi-line entry (such as the entry that announces all
-    the types that became opaque with OpenSSL 1.1.0).
+    security fixes, please add a line in [NEWS.md](NEWS.md).
+    On exception, it might be worth adding a multi-line entry (such as
+    the entry that announces all the types that became opaque with
+    OpenSSL 1.1.0).
     This file helps users get a very quick summary of what comes with a
     specific release, to see if an upgrade is worth the effort.
+
+ 9. Guidelines how to integrate error output of new crypto library modules
+    can be found in [crypto/err/README.md](crypto/err/README.md).
\ No newline at end of file