wording consistency

Author: Lms24

develop-docs/sdk/processes/releases.mdx

@@ -157,16 +157,16 @@ Specifically, craft expects versions following this format:
 <major>.<minor>.<patch>(-<prerelease>)?(-<build>)?
 ```
 
-While the major, minor and patch versions are required, prerelease and build properties are optional but can also be combined.
+While the major, minor and patch version numbers are required, pre-release and build properties are optional but can also be combined.
 
-### Prereleases (`<prerelease>`)
+### Pre-releases (`<prerelease>`)
 
-If you want to create a preview release of your SDK, you can append a prerelease identifier, as well as an optional incremental prerelease number to your version.
-This will ensure that various Craft publishing targets will treat the release as a prerelease, meaning for example that it will not get assigned a `latest` in package repositories.
-Likewise, prereleases will not be inserted into our internal release-registry, which is used by the Sentry product as well as our docs and other tools to query the latest or specific releases of our packages.
+If you want to create a preview or pre-release of your SDK, you can append a pre-release identifier, as well as an optional incremental pre-release number to your version.
+This will ensure that various craft publishing targets will treat the release as a pre-release, meaning for example that it will not get assigned a `latest` tag in package repositories.
+Likewise, pre-releases will not be inserted into our internal release-registry, which is used by the Sentry product as well as our docs and other tools to query the latest or specific releases of our packages.
 
-However, we have strict rules around which identifiers we accept as a prerelease. Therefore, the `<prerelease>` part of your version has to be one of the following: `preview|pre|rc|dev|alpha|beta|unstable|a|b`
-As a consequence, we **do not accept** arbitrary strings as prerelease identifiers. Using any other identifiers will result in a release being considered stable instead.
+Importantly, we have strict rules around which identifiers we accept as a pre-release, meaning the `<prerelease>` part of your version has to be one of the following: `preview|pre|rc|dev|alpha|beta|unstable|a|b`.
+Therefore, we **do not accept** arbitrary strings as pre-release identifiers. Using any other identifiers will result in a release being considered stable instead. This means, it will get assigned a `latest` tag in package repositories and inserted into our release-registry.
 
 Examples:
 
@@ -185,13 +185,13 @@ Examples:
 
 #### Special Case: Post Releases
 
-Python has the concept of post releases, which Craft handles implicitly. A post release is indicated by a `-\d+` suffix to the semver version, for example: `1.0.0-1`.
-Given that we only consider certain identifiers as [valid prerelease identifiers](#prereleases-prerelease), post releases are considered stable releases.
+Python has the concept of post releases, which craft handles implicitly. A post release is indicated by a `-\d+` suffix to the semver version, for example: `1.0.0-1`.
+Given that we only consider certain identifiers as [valid pre-release identifiers](#pre-releases-prerelease), post releases are considered stable releases.
 
 ### Build identifiers (`<build>`)
 
 In some cases, you can append a build identifier to your version, for example if you release the same package version for different platforms or architectures.
-You can also combine build and prerelease identifiers but in this case, the prerelease identifier has to come first.
+You can also combine build and pre-release identifiers but in this case, the pre-release identifier has to come first.
 
 Examples: