Azure · heaths · Aug 28, 2020 · Aug 28, 2020 · weshaggard · Aug 29, 2020
diff --git a/docs/dotnet/introduction.md b/docs/dotnet/introduction.md
@@ -771,7 +771,7 @@ Consistent version number scheme allows consumers to determine what to expect fr
 
 {% include requirement/MUST id="dotnet-version-semver" %} use _MAJOR_._MINOR_._PATCH_ format for the version of the library dll and the NuGet package.
 
-Use _-preview_._N_ suffix for preview package versions. For example, _1.0.0-preview.2_.
+Use _-beta_._N_ suffix for beta (formerly "preview") package versions. For example, _1.0.0-beta.2_.
 
 {% include requirement/MUST id="dotnet-version-change-on-release" %} change the version number of the client library when **ANYTHING** changes in the client library.
 

diff --git a/docs/golang/design.md b/docs/golang/design.md
@@ -53,7 +53,7 @@ Management-plane packages:
 
 {% include requirement/MUST id="golang-versioning-semver" %} release versions of modules in accordance with [semver 2.0](https://semver.org/spec/v2.0.0.html).
 
-{% include requirement/MUST id="golang-versioning-preview" %} clearly version prerelease modules.  For new modules, use a v0 major version with no suffix (v0.1.0).  For existing modules, use a `-preview` suffix (v1.1.0-preview, v2.0.0-preview).
+{% include requirement/MUST id="golang-versioning-preview" %} clearly version prerelease modules.  For new modules, use a v0 major version with no suffix (v0.1.0).  For existing modules, use a `-beta` suffix (v1.1.0-beta, v2.0.0-beta).
 
 ## Dependencies
 

diff --git a/docs/policies/adoption.md b/docs/policies/adoption.md
@@ -46,8 +46,8 @@ Language specific guidelines are first published in DRAFT.  This means that they
 
 * The guidelines are published in draft mode for at least 1 month to allow public comments.
 * The engineering systems are configured for producing client libraries in the language.
-* The Azure Core and Azure Identity libraries are published in preview to appropriate distribution points.
-* At least 2 Azure client libraries are published in preview to the appropriate distribution points.
+* The Azure Core and Azure Identity libraries are published in beta to appropriate distribution points.
+* At least 2 Azure client libraries are published in beta to the appropriate distribution points.
 * At least 1 user study has been conducted that studies the Azure Core and Azure Identity library usage (generally as part of a client library user study).
 * The guidelines have been reviewed by the architectural board and (if there is one) the language team in DevDiv.
 

diff --git a/docs/policies/releasenotes.md b/docs/policies/releasenotes.md
@@ -54,7 +54,7 @@ The release manager will produce the point-in-time snapshot of the versions and
 * For all on-time releases, the release manager will merge and publish the release notes in the current month's on-time release folder. 
 * For all out-of-band releases, the release notes in the following month's on-time release folder. 
 
-Release notes will locked for GA and preview libraries after the blog publication date (1 week following release date). (Note: all changelogs should be done on release day)
+Release notes will locked for GA and beta libraries after the blog publication date (1 week following release date). (Note: all changelogs should be done on release day)
 
 ## What do I need to do for an out-of-band release?
 

diff --git a/docs/policies/releases.md b/docs/policies/releases.md
diff --git a/docs/policies/repobranching.md b/docs/policies/repobranching.md
@@ -40,7 +40,7 @@ There are potentially 3 different types of release branches in the order of pref
 
 In general there should not be a need for release branches because most releases will happen directly from master. In some cases there may be a need to lock down the branch to stabilize a package and in these cases we should create a release branch named `release/<release name>` and push it to the main repository. We do this to avoid ever locking down the master branch from taking other work. After any changes have been made and the release build produced the branch should be merged (not rebased) back into master, including the tagged release commit, and then the release branch should be deleted.
 
-There may be other circumstances where we need to release a preview of a package from another branch outside of master or a release branch. In those cases we should use a feature branch in the main repository (note that we should not do stable releases out of feature branches so ensure the version is correctly marked as a preview). The release should be done in the same way, including the creation of the release tag, with the only difference being the release build should point to this feature branch instead of master. When the work is done this feature branch should be merged into master instead of rebased as generally recommended for feature branches. This allows us to preserve the release tags in master after we delete the feature branch.
+There may be other circumstances where we need to release a beta of a package from another branch outside of master or a release branch. In those cases we should use a feature branch in the main repository (note that we should not do stable releases out of feature branches so ensure the version is correctly marked as a beta). The release should be done in the same way, including the creation of the release tag, with the only difference being the release build should point to this feature branch instead of master. When the work is done this feature branch should be merged into master instead of rebased as generally recommended for feature branches. This allows us to preserve the release tags in master after we delete the feature branch.
 
 When doing any releases outside of master extra caution needs to be taken to ensure the version numbers are correct and don't conflict with master or any other branch that might be releasing the same package.
 

diff --git a/docs/policies/reviewprocess.md b/docs/policies/reviewprocess.md
@@ -18,7 +18,7 @@ Our common goal is to create a great developer experience on Azure.  New librari
 It's critical that library owners engage with the architecture board early enough to allow time for fixes and (sometimes significant) API redesign based on discussion. New libraries and/or large feature work should be discussed in an architecture board meeting three times:
 
 1. **Informational** - The first is purely informational/educational to enable the board to get up to speed with the library / new features that are coming.  This allows for early feedback and will potentially affect the service design.  High level topics such as API namespaces, function names, and types will be suggested in this first discussion.  See [What to prepare for the initial discussion](#what-to-prepare-for-the-initial-discussion) below.
-2. **Review** - The second is to propose and review the overall API shape in the core languages (.NET, Java, Python, and TypeScript) with an eye towards consistency. Occasionally, questions arise in the review for one language that will impact the implementation in other languages as well.  For this reason, it is encouraged that all languages are scheduled for review in the same board meeting or in board meetings within a 7 day period.  Ideally these reviews happen before most of the coding work has been done to implement the APIs.  This review should be done before the first public preview.  See [API Listings](#api-listings) below.
+2. **Review** - The second is to propose and review the overall API shape in the core languages (.NET, Java, Python, and TypeScript) with an eye towards consistency. Occasionally, questions arise in the review for one language that will impact the implementation in other languages as well.  For this reason, it is encouraged that all languages are scheduled for review in the same board meeting or in board meetings within a 7 day period.  Ideally these reviews happen before most of the coding work has been done to implement the APIs.  This review should be done before the first public beta.  See [API Listings](#api-listings) below.
 3. **Signoff** - The third is a final API signoff.  All languages must be signed off before any are released as GA.  When there have been limited changes made to the API since the second review, architects may choose to sign off over email without the need for a full meeting.
 
 See [Requesting a meeting with the board](#requesting-a-meeting-with-the-board) below for instructions on how to request one of these three meetings.
@@ -31,11 +31,11 @@ Remember that **all changes** to an API must be approved by the language archite
 
 ### Previewing API changes
 
-It is expected that API changes are released in preview or RC (release candidate) for a period of time before they are released as GA.  This gives customers time to provide feedback which could result in adjustments to the API before it GAs.  API changes that go straight to GA do not benefit from this feedback which can result in them being difficult for customers to use and for us to support.  In most circumstances, API changes going through either the full or abbreviated review process should be previewed (or RC) before GA.
+It is expected that API changes are released in beta or RC (release candidate) for a period of time before they are released as GA.  This gives customers time to provide feedback which could result in adjustments to the API before it GAs.  API changes that go straight to GA do not benefit from this feedback which can result in them being difficult for customers to use and for us to support.  In most circumstances, API changes going through either the full or abbreviated review process should be previewed (or RC) before GA.
 
 ### Tracking API changes that need to be reviewed
 
-While an API is in preview or after it is in GA, changes to APIs are not always obvious (to the developer or the reviewer) when they're being made so it's important that we identify them and review them to ensure the best SDK library experience for our customers. Long-term we will have tooling in place to detect API additions, changes, and breaks.  Until then, we will use the "APIChange" label on PRs to identify code changes that included a modification to an already released API.  This signals to that a language architect needs to review the change.  Once they've approved the change they would add the "ArchApproved" label.  Before release, a review of all changes merged into the library should be done to ensure that all "APIChange" labels are paired with an "ArchApproved" label.  Here is an [example query](https://github.com/Azure/azure-sdk-for-java/pulls?utf8=%E2%9C%93&q=is%3Apr+label%3AAPIChange+) for the Java libraries.  
+While an API is in beta or after it is in GA, changes to APIs are not always obvious (to the developer or the reviewer) when they're being made so it's important that we identify them and review them to ensure the best SDK library experience for our customers. Long-term we will have tooling in place to detect API additions, changes, and breaks.  Until then, we will use the "APIChange" label on PRs to identify code changes that included a modification to an already released API.  This signals to that a language architect needs to review the change.  Once they've approved the change they would add the "ArchApproved" label.  Before release, a review of all changes merged into the library should be done to ensure that all "APIChange" labels are paired with an "ArchApproved" label.  Here is an [example query](https://github.com/Azure/azure-sdk-for-java/pulls?utf8=%E2%9C%93&q=is%3Apr+label%3AAPIChange+) for the Java libraries.  
 
 When the library developers indicate they're ready to release, these should be reviewed by the architect as part of final signoff before GA.  Libraries should not be released as GA (or updated to GA) if there are unresolved "APIChange" labels without a corresponding "ArchApproved" label.  Once final review is requested, all "APIChange" labels will be responded to within 5 working days.
 

diff --git a/docs/python/implementation.md b/docs/python/implementation.md
@@ -310,7 +310,7 @@ class ResponseHook(Protocol):
 
 {% include requirement/MUST id="python-versioning-semver" %} use [semantic versioning](https://semver.org) for your package. 
 
-{% include requirement/MUST id="python-versioning-beta" %} use the `bN` pre-release segment for [preview releases](https://www.python.org/dev/peps/pep-0440/#pre-releases). 
+{% include requirement/MUST id="python-versioning-beta" %} use the `bN` pre-release segment for [beta releases](https://www.python.org/dev/peps/pep-0440/#pre-releases). 
 
 Don't use pre-release segments other than the ones defined in [PEP440](https://www.python.org/dev/peps/pep-0440) (`aN`, `bN`, `rcN`). Build tools, publication tools, and index servers may not sort the versions correctly.
 

diff --git a/docs/typescript/design.md b/docs/typescript/design.md
@@ -38,9 +38,9 @@ While consumers are fast at adopting new versions of TypeScript, version 3.1 is
 
 {% include requirement/MUST id="ts-namespace-serviceclient" %} pick a package name that allows the consumer to tie the namespace to the service being used.  As a default, use the compressed service name at the end of the namespace.  The namespace does **NOT** change when the branding of the product changes. Avoid the use of marketing names that may change.
 
-{% include requirement/MUST id="ts-npm-dist-tag-preview" %} tag preview packages with the npm distribution tag `next`. If there is no generally available release of this package, it should also be tagged `latest`.
+{% include requirement/MUST id="ts-npm-dist-tag-preview" %} tag beta packages with the npm distribution tag `next`. If there is no generally available release of this package, it should also be tagged `latest`.
 
-{% include requirement/MUST id="ts-npm-dist-tag-next" %} tag generally available npm packages `latest`. Generally available packages may also be tagged `next` if they include the changes from the most recent preview.
+{% include requirement/MUST id="ts-npm-dist-tag-next" %} tag generally available npm packages `latest`. Generally available packages may also be tagged `next` if they include the changes from the most recent beta.
 
 {% include requirement/MUST id="ts-namespace-in-browsers" %} use one of the appropriate namespaces (see below) for browser globals when producing UMD builds.
 

diff --git a/docs/typescript/implementation.md b/docs/typescript/implementation.md
@@ -273,9 +273,9 @@ A particular (major.minor) version of a library can choose what service APIs it
 
 {% include requirement/MUSTNOT id="ts-versioning-no-ga-prerelease" %} have a pre-release version or any additional build metadata for GA packages.
 
-{% include requirement/MUST id="ts-versioning-preview" %} give preview packages a pre-release version of the format `1.0.0-Preview.X` where X is an integer. Pre-release package versions shouldn't have additional build metadata.
+{% include requirement/MUST id="ts-versioning-preview" %} give beta packages a pre-release version of the format `1.0.0-beta.X` where X is an integer. Pre-release package versions shouldn't have additional build metadata.
 
-{% include requirement/MUSTNOT id="ts-versioning-no-version-0" %} use a major version of 0, even for preview packages.
+{% include requirement/MUSTNOT id="ts-versioning-no-version-0" %} use a major version of 0, even for beta packages.
 
 {% include requirement/MUST id="general-versioning-bump" %} select a version number greater than the highest version number of any other released Track 1 package for the service in any other npm scope or language.
 

diff --git a/eng/scripts/Update-Release-Versions.ps1 b/eng/scripts/Update-Release-Versions.ps1
@@ -103,6 +103,7 @@ function Update-java-Packages($packageList)
       Write-Warning "Not updating VersionGA for $($pkg.Package) because at least one associated URL is not valid!"
     }
 
+    # TODO: Do references to "latest-preview" need to be changed to "latest-beta"?
     $version = GetVersionWebContent "java" $pkg.Package "latest-preview"
     if ($version -eq "") {
       $pkg.VersionPreview = ""

diff --git a/eng/scripts/release-template/dotnet.md b/eng/scripts/release-template/dotnet.md
@@ -16,7 +16,7 @@ The Azure SDK team is pleased to announce our %%MMMM yyyy%% client library relea
 
 - _Add packages_
 
-#### Preview
+#### Beta
 
 - _Add packages_
 

diff --git a/eng/scripts/release-template/java.md b/eng/scripts/release-template/java.md
@@ -16,7 +16,7 @@ The Azure SDK team is pleased to announce our %%MMMM yyyy%% client library relea
 
 - _Add packages_
 
-#### Preview
+#### Beta
 
 - _Add packages_
 

diff --git a/eng/scripts/release-template/js.md b/eng/scripts/release-template/js.md
@@ -16,7 +16,7 @@ The Azure SDK team is pleased to make available the %%MMMM yyyy%% client library
 
 - _Add packages_
 
-#### Preview
+#### Beta
 
 - _Add packages_
 

diff --git a/eng/scripts/release-template/python.md b/eng/scripts/release-template/python.md
@@ -16,13 +16,13 @@ The Azure SDK team is pleased to make available the %%MMMM yyyy%% client library
 
 - _Add packages_
 
-#### Preview
+#### Beta
 
 - _Add packages_
 
 ## Installation Instructions
 
-To install the latest preview version of the packages, copy and paste the following commands into a terminal:
+To install the latest beta version of the packages, copy and paste the following commands into a terminal:
 
 ```bash
 $> pip install azure-packagename