release naming conventions

[stampFabian]

Feature branches:

Feature branches are typically named descriptively, indicating the feature or functionality being developed.
It's common to prefix feature branches with a feature/ or feat/ to distinguish them from other branch types.
Example: feature/user-authentication, feat/payment-integration

Release branches and tags:

Release branches:

Release branches are used to prepare a specific version of the software for release.
It's common to prefix release branches with release/ or release- to distinguish them from other branch types.
Example: release/1.0, release-2.3

Release tags:

Release tags are used to mark specific points in the project's history as a release.
Tags are typically named with a version number or a tag name related to the release.
Common practices include using semantic versioning or using specific tag names like v1.0 or v2.3.
Example: v1.0.0, v2.3-beta

Transitioning from 8.x-* to semantic versioning:

When transitioning from a non-semantic versioning scheme (e.g., 8.x-*) to semantic versioning, it's common to follow the standard semantic versioning format for releases and tags.
This may involve updating the existing release branches and tags to match the semantic versioning format.

Stable releases and pre-releases:

Stable releases are typically marked by using a specific version number without any additional labels or qualifiers.
Pre-releases, such as alpha, beta, or release candidate versions, may include additional labels or qualifiers to indicate their pre-release status.
It's common to use hyphens or other qualifiers to differentiate pre-releases from stable releases.
Example: 1.0.0-beta, 2.3.1-alpha.1

[AdamKITZ]

very good explanation