Update common files (#500)

.github/workflows/release.yml

@@ -146,7 +146,7 @@ jobs:
     if: startsWith(github.ref, 'refs/tags/')
     steps:
       - name: Checkout repository
-        uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608 # v4.1.0
+        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
       - name: Download artifacts
         uses: actions/download-artifact@9bc31d5ccc31df68ecc42ccf4149144866c47d8a # v3.0.2
         with:

.gitignore

@@ -32,4 +32,4 @@ src/main/docs/resources/style/*.html
 src/main/docs/resources/img/micronaut-logo-white.svg
 
 # Ignore files generated by test-resources
-**/.micronaut/test-resources/
+**/.micronaut/test-resources/

MAINTAINING.md

@@ -102,14 +102,14 @@ The consequence of having both approaches in place is that we get multiple depen
 `micronaut-build` via our automation, and one or many (one per dependency) created by Renovate. When merging those, it
 is better to prefer the `micronaut-build` ones, if possible, for 2 reasons: a) they attempt to upgrade multiple dependencies
 in a single PR, which creates less noise in the Git history; b) Once you merge that, Renovate will react and automatically
-close its own PRs if the dependecy is up-to-date.
+close its own PRs if the dependency is up-to-date.
 
 When an upgrade to a new version arrives, we need to be careful when merging, so that we don't introduce an
 unnecessary upgrade burden on our users. Read the
 [Module Upgrade Strategy](https://github.com/micronaut-projects/micronaut-core/wiki/Module-Upgrade-Strategy) for more
 information.
 
-Note that if a new version arrives and we are not ready yet to do the upgrade, you need to
+Note that if a new version arrives, and we are not ready yet to do the upgrade, you need to
 [pin the old version](https://github.com/micronaut-projects/micronaut-build/#configuration-options), because otherwise,
 Renovate and our workflow will keep sending PRs. You should also create an issue to upgrade so that it's not forgotten.
 
@@ -162,7 +162,7 @@ First of all, all the repos have an automatic changelog generation mechanism: wh
 release notes will contain pull requests merged and issues closed since the last release.
 
 When the module is ready for a new release, check the generated release notes, and make changes if needed (for example,
-you can add an introduction paragraph highligting some items included in the release). If the version you are going to
+you can add an introduction paragraph highlighting some items included in the release). If the version you are going to
 publish is not a new patch version, but a new minor or major, update the release notes text to reflect the new version.
 If you are publishing a milestone or release candidate, check the pre-release checkbox.
 

SECURITY.md

@@ -4,7 +4,7 @@ We release patches for security vulnerabilities. Which versions are eligible
 receiving such patches depend on the CVSS v3.0 Rating:
 
 | CVSS v3.0 | Supported Versions                        |
-| --------- | ----------------------------------------- |
+|-----------|-------------------------------------------|
 | 9.0-10.0  | Releases within the previous three months |
 | 4.0-8.9   | Most recent release                       |