diff --git a/release-guidelines.md b/release-guidelines.md
index 13c1bec97..85ef31685 100644
--- a/release-guidelines.md
+++ b/release-guidelines.md
@@ -6,7 +6,7 @@ Only stable, well tested components and packages may be present in the master or
 
 To develop your component create a new feature branch including your module name, for example if you are building a new tabs component you would create a branch named `feature-x-tabs`. Your component will stay in this branch until it is ready to be merged into the next major or minor release so you are encouraged to merge from or rebase onto the latest development or master branch regularly. You are welcome to raise pull requests against your feature branch if you need to.
 
-Because experimental modules will not be included in any stable releases we allow them to be published separately using a pre-1.0.0 version number. You are free to make as many prereleases as you need. To create a prerelease of your experimental module you must create a tag in the format `module-name-v0.x.x`, for example to release the tabs component you would create tag named `x-tabs-v0.0.1` for the latest commit in the `feature-x-tabs` branch.
+Because experimental modules will not be included in any stable releases we allow them to be published separately using a pre-1.0.0 version number. You are free to make as many prereleases as you need. To create a prerelease of your experimental module you must create a tag in the format `module-name-v0.x.x`, for example to release the tabs component you would create tag named `x-tabs-v0.0.1` for the latest commit in the `feature-x-tabs` branch. You may also use an identifier to namespace your prereleases, e.g. `x-tags-v0.0.1-beta.1`.
 
 When your new module is considered stable raise a pull request against the current development branch. Your module will be released as part of the next major or minor version.