diff --git a/Makefile b/Makefile
index b22527daec..9fdb588215 100644
--- a/Makefile
+++ b/Makefile
@@ -39,10 +39,6 @@ dev: binaries/client build-extensions static/build/LensDev.html
 lint:
 	yarn lint
 
-.PHONY: release-version
-release-version:
-	npm version $(CMD_ARGS) --git-tag-version false
-
 .PHONY: tag-release
 tag-release:
 	scripts/tag-release.sh $(CMD_ARGS)
diff --git a/RELEASE_GUIDE.md b/RELEASE_GUIDE.md
index b11a47c134..a2f7a6db32 100644
--- a/RELEASE_GUIDE.md
+++ b/RELEASE_GUIDE.md
@@ -2,15 +2,17 @@
 
 Lens releases are built by CICD automatically on git tags. The typical release process flow is the following:
 
+1. It is recommended to perform the release process from a folder used solely meant for creating releases (i.e. not your dev folder), with the Lens repo initialized (origin set to https://github.com/lensapp/lens).
+
 1. If doing a patch release checkout the `release/vMAJOR.MINOR` branch for the appropriate `MAJOR`/`MINOR` version and manually `cherry-pick` the PRs required for the patch that were commited to master. If there are any conflicts they must be resolved manually. If necessary, get assistance from the PR authors.
 
-1. From a clean and up to date `master` (or `release/vMAJOR.MINOR` if doing a patch release) run `make release-version <version-type>` where `<version-type>` is one of the following:
+1. From a clean and up to date `master` (or `release/vMAJOR.MINOR` if doing a patch release) run `npm version <version-type> --git-tag-version false` where `<version-type>` is one of the following:
     - `major`
     - `minor`
     - `patch`
-    - `premajor`
-    - `preminor`
-    - `prepatch`
+    - `premajor` [--preid=<prerelease-id>]
+    - `preminor` [--preid=<prerelease-id>]
+    - `prepatch` [--preid=<prerelease-id>]
     - `prerelease [--preid=<prerelease-id>]`
       
       where `<prerelease-id>` is generally one of:
@@ -18,7 +20,7 @@ Lens releases are built by CICD automatically on git tags. The typical release p
         - `beta`
         - `rc`
   
-    This assumes origin is set to https://github.com/lensapp/lens.git. If not then set GIT_REMOTE to the remote that is set to https://github.com/lensapp/lens.git. For example run `GIT_REMOTE=upstream make release-version ...`
+    This assumes origin is set to https://github.com/lensapp/lens.git. If not then set GIT_REMOTE to the remote that is set to https://github.com/lensapp/lens.git. For example run `GIT_REMOTE=upstream npm version ...`
 1. Open the PR (git should have printed a link to GitHub in the console) with the contents of all the accepted PRs since the last release. The PR description needs to be filled with the draft release description. From https://github.com/lensapp/lens click on Releases, the draft release should be first in the list, click `Edit` and copy/paste the markdown to the PR description. Add the `skip-changelog` label and click `Create Pull Request`. If this is a patch release be sure to set the PR base branch to `release/vMAJOR.MINOR` instead of `master`.
 1. After the PR is accepted and passes CI (and before merging), go to the same branch and run `make tag-release` (set GIT_REMOTE if necessary). This additionally triggers the azure jobs to build the binaries and put them on S3.
 1. If the CI fails at this stage the problem needs to be fixed. Sometimes an azure job fails due to outside service issues (e.g. Apple signing occasionally fails), in which case the specific azure job can be rerun from https://dev.azure.com/lensapp/lensapp/_build. Otherwise changes to the codebase may need to be done and committed to the release branch and pushed to https://github.com/lensapp/lens. CI will run again. As well the release tag needs to be manually set to this new commit. You can do something like: