Mention additional use-case in README

Mention another use-case in the README file, making sure that users have some idea where & when the crate can be useful.
d-e-s-o · Aug 20, 2024 · 044f591 · 044f591
1 parent d2b9ac8
commit 044f591
Show file tree

Hide file tree

Showing 3 changed files with 9 additions and 2 deletions.
diff --git a/.github/workflows/publish.yml b/.github/workflows/publish.yml
@@ -50,7 +50,7 @@ jobs:
           --request POST \
           --url https://api.github.com/repos/${{ github.repository }}/releases \
           --header "Accept: application/vnd.github+json" \
-          --header "Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}"\
+          --header "Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}" \
           --header "X-GitHub-Api-Version: 2022-11-28" \
           --data "{
               \"tag_name\":\"v${version}\",

diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -1,3 +1,8 @@
+Unreleased
+----------
+- Added additional use case to README
+
+
 0.1.3
 -----
 - Added generation of top-level import of original test function to

diff --git a/README.md b/README.md
@@ -35,7 +35,9 @@ Please note that the usage of Miri is just an example (if the majority
 of tests is Miri-compatible you can use `#[cfg_attr(miri, ignore)]` as
 an opt-out alternative). However, tagging can be useful for other
 properties, such as certain tests requiring alleviated rights (need to
-be run with administrator privileges).
+be run with administrator privileges) or those being eligible for
+running on a partly supported (perhaps to-be-onboarded) operating
+system.
 
 Usage
 -----