Use Alpha and Beta for our prerelease tags instead of dev and preview for all languages

docs/dotnet/introduction.md

@@ -312,7 +312,7 @@ namespace Azure.Storage.Blobs {
 }
 namespace Azure.Storage.Blobs.Models {
     ...
-    public class BlobContainerItem { ... } 
+    public class BlobContainerItem { ... }
     public class BlobContainerProperties { ...}
     ...
 }
@@ -338,8 +338,8 @@ In practice, you need to provide public APIs to construct _model graphs_. See [S
 
 ### Returning Collections {#dotnet-paging}
 
-Many Azure REST APIs return collections of data in batches or pages. A client library will expose such APIs as special enumerable types ```Pageable<T>``` or ```AsyncPageable<T>```. 
-These types are located in the ```Azure.Core``` package. 
+Many Azure REST APIs return collections of data in batches or pages. A client library will expose such APIs as special enumerable types ```Pageable<T>``` or ```AsyncPageable<T>```.
+These types are located in the ```Azure.Core``` package.
 
 For example, the configuration service returns collections of items as follows:
 
@@ -366,7 +366,7 @@ Service methods fall into two main groups when it comes to the number and comple
 
 _Simple methods_ are methods that take up to six parameters, with most of the parameters being simple BCL primitives. _Complex methods_ are methods that take large number of parameters and typically correspond to REST APIs with complex request payloads.
 
-_Simple methods_ should follow standard .NET Design Guidelines for parameter list and overload design. 
+_Simple methods_ should follow standard .NET Design Guidelines for parameter list and overload design.
 
 _Complex methods_ should use _option parameter_ to represent the request payload, and consider providing convenience simple overloads for most common scenarios.
 
@@ -385,7 +385,7 @@ public class BlobContainerClient {
 
 public class BlobCreateOptions {
     public PublicAccessType Access { get; set; }
-    public IDictionary<string, string> Metadata { get; } 
+    public IDictionary<string, string> Metadata { get; }
     public BlobContainerEncryptionScopeOptions Encryption { get; set; }
     ...
 }
@@ -395,9 +395,9 @@ public class BlobCreateOptions {
 
 {% include requirement/MAY id="dotnet-params-complex" %} use the _options_ parameter pattern for simple service methods that you expect to `grow` in the future.
 
-{% include requirement/MAY id="dotnet-params-complex" %} add simple overloads of methods using the _options_ parameter pattern. 
+{% include requirement/MAY id="dotnet-params-complex" %} add simple overloads of methods using the _options_ parameter pattern.
 
-If in common scenarios, users are likely to pass just a small subset of what the _options_ parameter represents, consider adding an overload with a parameter list representing just this subset.  
+If in common scenarios, users are likely to pass just a small subset of what the _options_ parameter represents, consider adding an overload with a parameter list representing just this subset.
 
 #### Parameter Validation
 
@@ -413,7 +413,7 @@ Common parameter validations include null checks, empty string checks, and range
 
 ### Long Running Operations {#dotnet-longrunning}
 
-Some service operations, known as _Long Running Operations_ or _LROs_ take a long time (up to hours or days). Such operations do not return their result immediately, but rather are started, their progress is polled, and finally the result of the operation is retrieved. 
+Some service operations, known as _Long Running Operations_ or _LROs_ take a long time (up to hours or days). Such operations do not return their result immediately, but rather are started, their progress is polled, and finally the result of the operation is retrieved.
 
 Azure.Core library exposes an abstract type called ```Operation<T>```, which represents such LROs and supports operations for polling and waiting for status changes, and retrieving the final operation result.
 
@@ -445,7 +445,7 @@ public class CopyFromUriOperation : Operation<long> {
 }
 
 public class BlobBaseClient {
-    
+
     public virtual CopyFromUriOperation StartCopyFromUri(..., CancellationToken cancellationToken = default);
     public virtual Task<CopyFromUriOperation> StartCopyFromUriAsync(..., CancellationToken cancellationToken = default);
 }
@@ -676,7 +676,7 @@ Request logging will be done automatically by the `HttpPipeline`.  If a client l
 
 {% include requirement/MUST id="dotnet-packaging-nuget" %} package all components as NuGet packages.
 
-If your client library is built by the Azure SDK engineering systems, all packaging requirements will be met automatically. Follow the [.NET packaging guidelines](https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/nuget) if you're self-publishing. For Microsoft owned packages we need to support both windows (for windows dump diagnostics) and portable (for x-platform debugging) pdb formats which means you need to publish them to the Microsoft symbol server and not the Nuget symbol server which only supports portable pdbs. 
+If your client library is built by the Azure SDK engineering systems, all packaging requirements will be met automatically. Follow the [.NET packaging guidelines](https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/nuget) if you're self-publishing. For Microsoft owned packages we need to support both windows (for windows dump diagnostics) and portable (for x-platform debugging) pdb formats which means you need to publish them to the Microsoft symbol server and not the Nuget symbol server which only supports portable pdbs.
 
 {% include requirement/MUST id="dotnet-packaging-naming" %} name the package based on the name of the main namespace of the component.
 
@@ -723,7 +723,7 @@ Use a constructor parameter called `version` on the client options type.
 * The `version` parameter must be the first parameter to all constructor overloads.
 * The `version` parameter must be required, and default to the latest supported service version.
 * The type of the `version` parameter must be `ServiceVersion`; an enum nested in the options type.
-* The `ServiceVersion` enum must use explicit values starting from 1. 
+* The `ServiceVersion` enum must use explicit values starting from 1.
 * `ServiceVersion` enum value 0 is reserved. When 0 is passed into APIs, ArgumentException should be thrown.
 
 For example, the following is a code snippet from the `ConfigurationClientOptions`:
@@ -732,7 +732,7 @@ For example, the following is a code snippet from the `ConfigurationClientOption
 public class ConfigurationClientOptions : ClientOptions {
 
     public ConfigurationClientOptions(ServiceVersion version = ServiceVersion.V2019_05_09) {
-        if (version == default) 
+        if (version == default)
             throw new ArgumentException($"The service version {version} is not supported by this library.");
         }
     }
@@ -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 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.
 

docs/general/design.md

@@ -59,7 +59,7 @@ Here are some namespaces that do not meet the guidelines:
 
 ## Client interface
 
-The API surface will consist of one of more _service clients_ that the consumer will instantiate to connect to your service, plus a set of supporting types.     
+The API surface will consist of one of more _service clients_ that the consumer will instantiate to connect to your service, plus a set of supporting types.
 
 {% include requirement/MUST id="general-client-naming" %} name service client types with the `client` suffix.
 
@@ -91,11 +91,11 @@ The purposes of the client library is to communicate with an Azure service.  Azu
 
 {% include requirement/MUST id="general-service-apiversion-5" %} document the service API version that is used by default.
 
-{% include requirement/MUST id="general-service-apiversion-3" %} target the latest public preview API version by default when releasing a public preview version of the client library.
+{% include requirement/MUST id="general-service-apiversion-3" %} target the latest public preview API version by default when releasing a public beta version of the client library.
 
 {% include requirement/MUST id="general-service-apiversion-4" %} include all service API versions that are supported by the client library in a `ServiceVersion` enumerated value.
 
-{% include requirement/MUST id="general-service-apiversion-6" %} ensure that the values of the `ServiceVersion` enumerated value "match" the version strings in the service Swagger definition.  
+{% include requirement/MUST id="general-service-apiversion-6" %} ensure that the values of the `ServiceVersion` enumerated value "match" the version strings in the service Swagger definition.
 
 For the purposes of this requirement, semantic changes are allowed.  For instance, many version strings are based on SemVer, which allows dots and dashes.  However, these characters are not allowed in identifiers.  The developer **MUST** be able to clearly understand what service API version will be used when the service version is set to each value in the `ServiceVersion` enumerated value.
 
@@ -140,7 +140,7 @@ The following table enumerates the various models you might create:
 
 ## Network requests
 
-Since the client library generally wraps one or more HTTP requests, it is important to support standard network capabilities.  Asynchronous programming techniques are not widely understood, although such techniques are essential in developing scalable web services and required in certain environments (such as mobile or Node environments).  Many developers prefer synchronous method calls for their easy semantics when learning how to use a technology.  In addition, consumers have come to expect certain capabilities in a network stack - capabilities such as call cancellation, automatic retry, and logging. 
+Since the client library generally wraps one or more HTTP requests, it is important to support standard network capabilities.  Asynchronous programming techniques are not widely understood, although such techniques are essential in developing scalable web services and required in certain environments (such as mobile or Node environments).  Many developers prefer synchronous method calls for their easy semantics when learning how to use a technology.  In addition, consumers have come to expect certain capabilities in a network stack - capabilities such as call cancellation, automatic retry, and logging.
 
 {% include requirement/MUST id="general-network-support-sync-and-async" %} support both synchronous and asynchronous method calls, except where the language or default runtime does not support one or the other.
 
@@ -172,7 +172,7 @@ Here is an example of how an application would use the tree of cancellations:
 {% include requirement/MUSTNOT id="general-network-no-leakage" %} leak the underlying protocol transport implementation details to the consumer.  All types from the protocol transport implementation must be appropriately abstracted.
 
 ## Authentication
-Azure services use a variety of different authentication schemes to allow clients to access the service.  Conceptually, there are two entities responsible in this process: a credential and an authentication policy.  Credentials provide confidential authentication data.  Authentication policies use the data provided by a credential to authenticate requests to the service.  
+Azure services use a variety of different authentication schemes to allow clients to access the service.  Conceptually, there are two entities responsible in this process: a credential and an authentication policy.  Credentials provide confidential authentication data.  Authentication policies use the data provided by a credential to authenticate requests to the service.
 
 Primarily, all Azure services should support Azure Active Directory OAuth token authentication, and all clients must support authenticating requests in this manner.
 
@@ -224,7 +224,7 @@ The *logical entity* is a protocol neutral representation of a response. For HTT
 
 {% include requirement/MUST id="general-response-streaming" %} provide examples on how to access the raw and streamed response for a given request, where exposed by the client library.  We do not expect all methods to expose a streamed response.
 
-{% include requirement/MUST id="general-response-enumeration" %} provide a language idiomatic way to enumerate all logical entities for a paged operation, automatically fetching new pages as needed.  
+{% include requirement/MUST id="general-response-enumeration" %} provide a language idiomatic way to enumerate all logical entities for a paged operation, automatically fetching new pages as needed.
 
 For example, in Python:
 
@@ -299,7 +299,7 @@ In all cases, the conditional expression is "opt-in", and the default is to perf
 
 The return value from a conditional operation must be carefully considered.  For safe operators (e.g. GET), return a response that will throw if the value is accessed (or follow the same convention used fro a `204 No Content` response), since there is no value in the body to reference.  For unsafe operators (e.g. PUT, DELETE, or POST), throw a specific error when a `Precondition Failed` or `Conflict` result is received.  This allows the consumer to do something different in the case of conflicting results.
 
-{% include requirement/SHOULD %} accept a `conditions` parameter (which takes an enumerated type) on service methods that allow a conditional check on the service. 
+{% include requirement/SHOULD %} accept a `conditions` parameter (which takes an enumerated type) on service methods that allow a conditional check on the service.
 
 {% include requirement/SHOULD %} accept an additional boolean or enum parameter on service methods as necessary to enable conditional checks using `ETag`.
 
@@ -345,7 +345,7 @@ Long-running operations are operations which consist of an initial request to st
 {% include requirement/MUST id="general-lro-polling-config" %} support the following polling configuration options:
 
 * `pollInterval`
-  
+
 Polling configuration may be used only in the absence of relevant retry-after headers from service, and otherwise should be ignored.
 
 {% include requirement/MUST id="general-lro-prefix" %} prefix method names which return a poller with either `begin` or `start`.  Language-specific guidelines will dictate which verb to use.
@@ -373,6 +373,6 @@ For example, MQTT over WebSockets provides the ability to add headers during the
 
 {% include requirement/MUST id="general-proto-adparch" %} consult the [Architecture Board] on policy decisions for non-HTTP protocols.  Implementation of all policies is expected.  If the protocol cannot support a policy, obtain an exception from the [Architecture Board].
 
-{% include requirement/MUST id="general-proto-config" %} use the global configuration established in the Azure Core library to configure policies for non-HTTP protocols.  Consumers don't necessarily know what protocol is used by the client library.  They will expect the client library to honor global configuration that they have established for the entire Azure SDK.  
+{% include requirement/MUST id="general-proto-config" %} use the global configuration established in the Azure Core library to configure policies for non-HTTP protocols.  Consumers don't necessarily know what protocol is used by the client library.  They will expect the client library to honor global configuration that they have established for the entire Azure SDK.
 
 {% include refs.md %}

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-beta" %} 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
 
@@ -167,7 +167,7 @@ func NewWidgetClientFromConnectionString(ctx context.Context, con string, option
 
 When implementing authentication, don't open up the consumer to security holes like PII (personally identifiable information) leakage or credential leakage. Credentials are generally issued with a time limit, and must be refreshed periodically to ensure that the service connection continues to function as expected. Ensure your client library follows all current security recommendations and consider an independent security review of the client library to ensure you're not introducing potential security problems for the consumer.
 
-{% include requirement/MUSTNOT id="golang-auth-persistence" %} persist, cache, or reuse security credentials. Security credentials should be considered short lived to cover both security concerns and credential refresh situations. 
+{% include requirement/MUSTNOT id="golang-auth-persistence" %} persist, cache, or reuse security credentials. Security credentials should be considered short lived to cover both security concerns and credential refresh situations.
 
 {% include requirement/MUST id="golang-auth-policy-impl" %} provide a suitable authentication policy policy if your service implements a non-standard authentication system (that is, an authentication system that is not supported by Azure Core).  You also need to produce an authentication policy for the HTTP pipeline that can add credentials to requests given the alternative authentication mechanism provided by the service.  Custom credentials will need to implement the `azcore.Credentials` interface.
 
@@ -314,7 +314,7 @@ func (c *WidgetClient) ListWidgets(options *ListWidgetOptions) *WidgetPager {
 }
 
 pager := client.ListWidgets(options)
-for pager.NextPage(ctx) { 
+for pager.NextPage(ctx) {
 	for _, w := range pager.PageResponse().Widgets {
 		process(w)
 	}
@@ -339,7 +339,7 @@ type WidgetPoller interface {
 	// Done returns true if the LRO has completed.
 	Done() bool
 
-	// ResumeToken returns a value representing the poller that can be used to 
+	// ResumeToken returns a value representing the poller that can be used to
 	// resume the LRO. ResumeTokens are unique for the operation.
 	ResumeToken() string
 
@@ -353,7 +353,7 @@ type WidgetPoller interface {
 	// updated and returns the latest HTTP response.
 	Poll(context.Context) (*http.Response, error)
 
-	// FinalResponse performs a final GET to the service and returns the final response 
+	// FinalResponse performs a final GET to the service and returns the final response
 	// for the polling operation. If there is an error performing the final GET then an error is returned.
 	// If the final GET succeeded then the final WidgetResponse will be returned.
 	FinalResponse(context.Context) (*WidgetResponse, error)
@@ -450,7 +450,7 @@ if err != nil {
 for {
 	resp, err := poller.Poll(context.Background())
 	if err != nil {
-		// handle error ... 
+		// handle error ...
 	}
 	if poller.Done() {
 		break
@@ -627,7 +627,7 @@ Storage could support:
 * `AZURE_STORAGE_DNS_SUFFIX`
 * `AZURE_STORAGE_CONNECTION_STRING`
 
-{% include requirement/MUST id="golang-envvars-approval" %} get approval from the [Architecture Board] for every new environment variable. 
+{% include requirement/MUST id="golang-envvars-approval" %} get approval from the [Architecture Board] for every new environment variable.
 
 {% include requirement/MUST id="golang-envvars-syntax" %} use this syntax for environment variables specific to a particular Azure service: