Fix terminology for SDK releases (#3968)

.github/ISSUE_TEMPLATE/adp_review_service_intro.md

@@ -20,7 +20,7 @@ Please reference our [review process guidelines](https://azure.github.io/azure-s
 
 * Service team responsible for the client library:
 * Main contacts:
-* Expected GA date for this library:
+* Expected stable release date for this library:
 
 ## About the Service 
 

docs/general/design.md

@@ -85,9 +85,9 @@ The following are standard verb prefixes.  You should have a good (articulated)
 
 The purposes of the client library is to communicate with an Azure service.  Azure services support multiple API versions.  To understand the capabilities of the service, the client library must be able to support multiple service API versions.
 
-{% include requirement/MUST id="general-service-apiversion-1" %} only target generally available service API versions when releasing a GA version of the client library.
+{% include requirement/MUST id="general-service-apiversion-1" %} only target generally available service API versions when releasing a stable version of the client library.
 
-{% include requirement/MUST id="general-service-apiversion-2" %} target the latest generally available service API version by default in GA versions of the client library.
+{% include requirement/MUST id="general-service-apiversion-2" %} target the latest generally available service API version by default in stable versions of the client library.
 
 {% include requirement/MUST id="general-service-apiversion-5" %} document the service API version that is used by default.
 

docs/ios/design.md

@@ -1007,7 +1007,7 @@ Consistent version number scheme allows consumers to determine what to expect fr
 
 {% include requirement/MUST id="ios-versioning-major" %} increment the major version if there are breaking changes in the Azure SDK. Breaking changes require prior approval from the [Architecture Board].
 
-The bar to make a breaking change is extremely high for GA client libraries. We may create a new package with a different name to avoid diamond dependency issues.
+The bar to make a breaking change is extremely high for stable client libraries. We may create a new package with a different name to avoid diamond dependency issues.
 
 ### Dependencies
 

docs/policies/releases.md

@@ -162,9 +162,9 @@ Example change log:
 
 For clarity, a `change log entry` is simply the header + content up to the next release header OR EOF. During release, if there exists a changelog entry with a version specifier _matching_ that of the currently releasing package, that changelog entry will be added as the body of the GitHub release.
 
-### Changelog Entries for GA releases
+### Changelog Entries for Stable releases
 
-When doing a switch from a beta to a GA release there are often very few changes which can be misleading to customers, as they might not think there are many changes. Instead when doing a GA release it is recommended that we either squash all the beta notes into the GA changelog entry or add a comment similar to `Includes all changes from X.Y.Z-beta.A to X.Y.Z.beta.B` so that it is clear that all those changes are included.
+When doing a switch from a beta to a stable release there are often very few changes which can be misleading to customers, as they might not think there are many changes. Instead when doing a stable release it is recommended that we either squash all the beta notes into the stable changelog entry or add a comment similar to `Includes all changes from X.Y.Z-beta.A to X.Y.Z.beta.B` so that it is clear that all those changes are included.
 
 ## Release Cycle
 
@@ -183,10 +183,10 @@ The team makes every effort to follow [SemVer](https://semver.org/) for versioni
 - Increments to the minor digit (1.1.X to 1.2.X) indicate the addition of new apis or features.
 - Increments to the patch number (1.1.1 to 1.1.2) indicate a set of new compatible fixes.
 
-In addition to the stable GA releases the team also has prereleases of a package to allow the community to try new features early and give feedback.
+In addition to the stable releases the team also has Alpha and Beta releases of a package to allow the community to try new features early and give feedback.
 
 - Alpha releases are sometimes referred to as dev releases and use a prerelease label that contains a date stamp similar to `-alpha-YYYYMMDD.r`. This ensures the versions are unique as they will often be published daily. These are often published to an isolated registry depending on the language ecosystem. These releases are based on the latest committed code changes and should not be used for production dependencies. They are very volatile and change from version-to-version. These are mostly useful for temporarily working around an issue or testing out the latest library changes.
-- Beta releases use a prerelease label like `-beta.X` and are published to the most common public registry for each language ecosystem. These releases are less volatile and released less often then alpha releases.  These are usually used before releasing a new minor or major GA release. Beta releases may have breaking changes from the previous beta but should not have breaking changes from the last GA release. Once a package has released to GA, any breaking changes require an exception and approval from the architecture board.
+- Beta releases use a prerelease label like `-beta.X` and are published to the most common public registry for each language ecosystem. These releases are less volatile and released less often then alpha releases.  These are usually used before releasing a new minor or major stable release. Beta releases may have breaking changes from the previous beta but should not have breaking changes from the last stable release. Once a package has released to stable, any breaking changes require an exception and approval from the architecture board.
 
 While all the languages follow the general versioning scheme, they each have slight differences based on their ecosystem, for those differences see the individual language sections below.
 
@@ -198,9 +198,9 @@ Immediately after a package ships the source definition of the package version s
 
 **Beta Release:** Increment the beta number on the package (e.g. `1.0.0-beta.1` -> `1.0.0-beta.2`) appropriate to the versioning scheme for the language (see below for language-specific version formatting). Breaking changes are allowed between beta versions.
 
-**GA Release:** Some languages bump the minor and others bump the patch version please see specific guidelines below based on your language. Breaking changes (which might increment the major version number) are *not* allowed after a GA release without an exception and review by the architecture board.
+**Stable Release:** Some languages bump the minor and others bump the patch version please see specific guidelines below based on your language. Breaking changes (which might increment the major version number) are *not* allowed after a stable release without an exception and review by the architecture board.
 
-**GA Hotfix Release:** Some languages bump the patch version and others have specific conventions see guidelines below based on your language. See [Hotfix Branches](repobranching.md#hotfix-branches) for branching strategy of hotfixes.
+**Stable Hotfix Release:** Some languages bump the patch version and others have specific conventions see guidelines below based on your language. See [Hotfix Branches](repobranching.md#hotfix-branches) for branching strategy of hotfixes.
 
 ### Consistent Dependency Versions
 
@@ -244,11 +244,11 @@ Beta packages will be published PyPi. Alpha packages will be published to the is
 
 **Beta Release:**  `1.0.0b1` -> `1.0.0b2`
 
-**GA Release:** `1.1.0` ->  `1.1.1`
+**Stable Release:** `1.1.0` ->  `1.1.1`
 
-**GA Hotfix Release:** `1.1.0` ->  `1.1.0.1`
+**Stable Hotfix Release:** `1.1.0` ->  `1.1.0.1`
 
-**Floating GA dependencies:** Use `<X+1.0.0,>=X.0.0` to float dependencies where `X` is the major release upon which the package depends and `X+1` is the next major version.
+**Floating Stable dependencies:** Use `<X+1.0.0,>=X.0.0` to float dependencies where `X` is the major release upon which the package depends and `X+1` is the next major version.
 
 In rare cases where a customer cannot take all the latest patch versions with all the bug fixes for a particular major/minor release, but there is a critical fix necessary, we will publish a hotfix package in the format X.Y.Z.N where N increments with each successive hotfix. In this case it is expected that the customer will pin the particular hotfix version they wish to use.
 
@@ -259,28 +259,28 @@ When publishing an npm package, [npm distribution tags](https://docs.npmjs.com/c
 
 Below are the guidelines for versions to use:
 
-- GA releases will follow [SemVer](https://semver.org/) and the published package will get the tag `latest`.
+- Stable releases will follow [SemVer](https://semver.org/) and the published package will get the tag `latest`.
   - If a hotfix is being shipped for a version older than the current GA version, then the hotfix version does not get any tags.
-  - If a package has moved from beta to GA, then `next` tag is deleted  from beta and latest tag will be set for GA version.
+  - If a package has moved from beta to stable, then `next` tag is deleted from beta and latest tag will be set for stable version.
 - Beta releases will use the format `X.Y.Z-beta.N` for version and the published package will get the tag `next`.
-  - Package version will also get `latest` tag **only** if the package has never had a GA release.
+  - Package version will also get `latest` tag **only** if the package has never had a stable release.
 - Daily alpha releases will use the format `X.Y.Z-alpha.YYYYMMDD.r` (`r` is based on the number of builds performed on the given day) and the latest published package will have the `dev` tag and published to npm. To consume a alpha package either pin to a specific version or use the `dev` tag as the version.
 
 ##### Incrementing after release (JS)
 
 **Beta Release:** `1.0.0-beta.1` -> `1.0.0-beta.2`
 
-**GA Release:** `1.1.0` -> `1.1.1`
+**Stable Release:** `1.1.0` -> `1.1.1`
 
-**GA Hotfix Release:** `1.0.0` -> `1.0.0-hotfix.1`
+**Stable Hotfix Release:** `1.0.0` -> `1.0.0-hotfix.1`
 
-**Floating GA dependencies:** Use `^X.0.0` to float dependencies where `X` is the major release upon which the package depends.
+**Floating Stable dependencies:** Use `^X.0.0` to float dependencies where `X` is the major release upon which the package depends.
 
 Generally, customers are expected to use caret or tilde ranges. Caret ranges (e.g. `^1.0.0`) allow them to take all non-breaking changes for a package and tilde ranges (`~1.0.0`) allow them to take all minor bugfixes for a particular major/minor release.
 
 In rare cases where a customer does not wish to take all bugfixes for a particular major/minor release (i.e. the tilde range `~X.Y.0` is not sufficient), but there is a critical fix necessary, we will publish a hotfix package in the format `X.Y.0-hotfix.N` where `N` increments with each successive hotfix. In this case it is expected that the customer will pin the particular hotfix version they wish to use in their `package.json`.
 
-In general, packages that have GA'd are not expected to have additional beta releases unless the underlying service releases preview functionality or the package undergoes significant churn as part of a major version change.
+In general, packages that have a stable release are not expected to have additional beta releases unless the underlying service releases preview functionality or the package undergoes significant churn as part of a major version change.
 
 Packages which depend on a released package should float to the latest compatible major version (e.g. `^1.0.0`). Because we're using SemVer only breaking changes alter the major version number and all minor and patch changes should be compatible. The version number should only be updated for a major version change.
 
@@ -305,11 +305,11 @@ Beta packages will be published to NuGet with the pre-release designation. Alpha
 
 **Beta Release:** `1.0.0-beta.1` -> `1.0.0-beta.2`
 
-**GA Release:** `1.1.0` -> `1.2.0-beta.1`
+**Stable Release:** `1.1.0` -> `1.2.0-beta.1`
 
-**GA Hotfix Release:** `1.0.0` -> `1.0.1`
+**Stable Hotfix Release:** `1.0.0` -> `1.0.1`
 
-**Floating GA dependencies:** Use the exact version number to specify the lowest version of the package which contains the features upon which you depend.
+**Floating Stable dependencies:** Use the exact version number to specify the lowest version of the package which contains the features upon which you depend.
 
 #### Java
 
@@ -324,11 +324,11 @@ Beta packages are published directly to the Maven central registry. Alpha packag
 
 **Beta Release:** `1.0.0-beta.1` -> `1.0.0-beta.2`
 
-**GA Release:** `1.1.0` -> `1.2.0-beta.1`
+**Stable Release:** `1.1.0` -> `1.2.0-beta.1`
 
-**GA Hotfix Release:** `1.0.0` -> `1.0.1`
+**Stable Hotfix Release:** `1.0.0` -> `1.0.1`
 
-**Floating GA dependencies:** Use the exact version number to specify the lowest version of the package which contains the features upon which you depend.
+**Floating Stable dependencies:** Use the exact version number to specify the lowest version of the package which contains the features upon which you depend.
 
 #### C++
 
@@ -340,9 +340,9 @@ A C++ release includes a Tag and Release (e.g. [azure-core_1.0.0-beta.1](https:/
 
 **Preview release:** `1.0.0-beta.1` -> `1.0.0-beta.2`
 
-**GA Release:** `1.1.0` -> `1.2.0-beta.1`
+**Stable Release:** `1.1.0` -> `1.2.0-beta.1`
 
-**GA Hotfix Release:** `1.0.0` -> `1.0.1`
+**Stable Hotfix Release:** `1.0.0` -> `1.0.1`
 
 #### Embedded C
 
@@ -354,9 +354,9 @@ An Embedded C release includes a Tag and Release (e.g. [1.0.0-preview.5](https:/
 
 **Preview release:** `1.0.0-beta.1` -> `1.0.0-beta.2`
 
-**GA Release:** `1.1.0` -> `1.2.0-beta.1`
+**Stable Release:** `1.1.0` -> `1.2.0-beta.1`
 
-**GA Hotfix Release:** `1.0.0` -> `1.0.1`
+**Stable Hotfix Release:** `1.0.0` -> `1.0.1`
 
 #### Android
 
@@ -371,9 +371,9 @@ Beta packages are published directly to the Maven central registry. Alpha packag
 
 **Beta Release:** `1.0.0-beta.1` -> `1.0.0-beta.2`
 
-**GA Release:** `1.1.0` -> `1.2.0-beta.1`
+**Stable Release:** `1.1.0` -> `1.2.0-beta.1`
 
-**GA Hotfix Release:** `1.0.0` -> `1.0.1`
+**Stable Hotfix Release:** `1.0.0` -> `1.0.1`
 
 #### iOS
 
@@ -385,9 +385,9 @@ An iOS release includes a Tag and Release (e.g. [1.0.0-beta.2](https://github.co
 
 **Preview release:** `1.0.0-beta.1` -> `1.0.0-beta.2`
 
-**GA Release:** `1.1.0` -> `1.2.0-beta.1`
+**Stable Release:** `1.1.0` -> `1.2.0-beta.1`
 
-**GA Hotfix Release:** `1.0.0` -> `1.0.1`
+**Stable Hotfix Release:** `1.0.0` -> `1.0.1`
 
 #### Go
 
@@ -405,11 +405,11 @@ Initial Go package releases will be versioned will use `v0` versioning with `v0.
 
 **Beta Release:** `v2.0.0-beta.1` -> `v2.0.0-beta.2`
 
-**GA Release:** `v1.0.0` -> `v1.0.1`
+**Stable Release:** `v1.0.0` -> `v1.0.1`
 
-**GA Hotfix Release:** `v1.0.0` -> `v1.0.1`
+**Stable Hotfix Release:** `v1.0.0` -> `v1.0.1`
 
-## Beta Releases and GA Graduation
+## Beta Releases and Stable Graduation
 
 The Azure SDK team may choose to create a beta release for several reasons:
 
@@ -440,7 +440,7 @@ To create a beta, the release must:
 
 - Support for at least 2 languages.  Preferably, support one statically typed language (such as C# or Java) and one dynamically typed language (such as TypeScript or Python).
 
-To graduate to GA, a beta release must:
+To graduate to stable, a beta release must:
 
 - Support all four tier-1 languages (.NET, Java, Python, TypeScript) unless there is a good (and documented) reason to not include support for one of the languages.
 

docs/policies/reviewprocess.md

@@ -95,7 +95,7 @@ Depending on the situation and service, more than one API review may be needed (
 
 The goal of the API sign-off meeting is to resolve any controversial/unsettled questions about the API. These questions can come from language architects or service teams.
 
-**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.
+**All languages must be signed off before any are released as stable.** 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.
 
 **What to bring (include the following in GitHub issue requesting for review):**
 * Links to API Listings for each language
@@ -160,7 +160,7 @@ If after an API Sign Off session the Architecture Board approves the release, th
 
 ## Previewing API Changes
 
-It is expected that API changes are released in beta 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 released as beta before GA.
+It is expected that API changes are released in beta for a period of time before they are released as stable. This gives customers time to provide feedback which could result in adjustments to the API before it moves to stable. API changes that go straight to stable 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 released as beta before a stable release.
 
 ## Getting Approval for Small, Targeted Changes and Bug Fixes
 
@@ -169,8 +169,8 @@ For small or targeted changes and bug fixes which modify APIs, the architect in
 Remember that **all** changes to an API must be approved by the language architect before release.
 
 ## 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 preview or after a stable release, 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.
+When the library developers indicate they’re ready to release, these should be reviewed by the architect as part of final signoff before the release. Libraries should not be released as stable (or updated to stable) 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.
 
 {% include refs.md %}

docs/policies/support.md

@@ -14,7 +14,7 @@ Azure SDK Lifecycle and support are governed by the latest [Microsoft Modern Lif
 Here are the stages of a typical package lifecycle (for major versions)
 
 1. **Beta** – A new SDK that is available for early access and feedback purposes and is not recommended for use in production.
-   The beta version support is limited to GitHub issues and response time is not guaranteed. Beta releases live typically for less than 1 year, after which they are either retired or released to GA.
+   The beta version support is limited to GitHub issues and response time is not guaranteed. Beta releases live typically for less than 1 year, after which they are either retired or released as stable.
 
 2. **Active** - The SDKs are generally available and fully supported, will receive new feature updates, as well as bug and security fixes.
    The major version will remain active for at least 12 months from the release date. Compatible updates for the major release are provided through minor versions, or patch versions.

docs/python/design.md

@@ -746,7 +746,7 @@ Don't use pre-release segments other than the ones defined in [PEP440](https://w
 
 {% include requirement/MUST id="python-versioning-major-cross-languages" %} select a version number greater than the highest version number of any other released Track 1 package for the service in any other scope or language.
 
-The bar to make a breaking change is extremely high for GA client libraries.  We may create a new package with a different name to avoid diamond dependency issues.
+The bar to make a breaking change is extremely high for stable client libraries.  We may create a new package with a different name to avoid diamond dependency issues.
 
 ### Dependencies
 

docs/typescript/design.md

@@ -57,7 +57,7 @@ The following are examples that do not meet the guidelines:
 * `@microsoft/cosmos` (not in `@azure` scope).
 * `@azure/digitaltwins` (not kebab-cased).
 
-{% include requirement/SHOULD id="ts-npm-package-name-follow-conventions" %} you should follow the casing conventions of any existing GA packages released in the `@azure` npm scope. It's not worth renaming a package just to align on naming conventions.
+{% include requirement/SHOULD id="ts-npm-package-name-follow-conventions" %} you should follow the casing conventions of any existing stable packages released in the `@azure` npm scope. It's not worth renaming a package just to align on naming conventions.
 
 ## The Client API {#ts-apisurface-serviceclient}
 

docs/typescript/implementation.md

@@ -279,7 +279,7 @@ A particular (major.minor) version of a library can choose what service APIs it
 
 {% include requirement/MUST id="ts-versioning-semver" %} version with [semver](https://semver.org/). Deprecated features and flags must offer an alternate stable or beta path for developers.
 
-{% include requirement/MUSTNOT id="ts-versioning-no-ga-prerelease" %} have a pre-release version or any additional build metadata for GA packages.
+{% include requirement/MUSTNOT id="ts-versioning-no-ga-prerelease" %} have a pre-release version or any additional build metadata for stable packages.
 
 {% include requirement/MUST id="ts-versioning-beta" %} 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.
 

eng/README.md

@@ -10,8 +10,8 @@ given package ecosystem as well as by reading release tags from our mono repos.
 
 - `Package` - This is the full name for the package as it appears on the package manager.
 - `GroupId` - This is only for Java and it contains the GroupId of the package. The Package field in Java's case only contains the ArtifactId.
-- `VersionGA` - This contains the latest GA version for the given package. If one does not exist, the field is empty.
-- `VersionPreview` - This contains the latest preview/beta/prerelease version for the given package. The field will be empty if there isn't a preview, or the preview is older than the latest GA.
+- `VersionGA` - This contains the latest stable version for the given package. If one does not exist, the field is empty.
+- `VersionPreview` - This contains the latest preview/beta/prerelease version for the given package. The field will be empty if there isn't a preview, or the preview is older than the latest stable.
 - `DisplayName` - This is a friendly name for the package that is used in the package index and other contexts to display a nicer name for the package.
 - `ServiceName` - This is the name of the service that this package is related to and is used in documentation contexts to group a set of packages for a given service together.
 - `RepoPath` - This contains information to create a link to the github repo for the given package. For our standard services that ship from our mono repos this should just be name of the service directory (e.g. `/sdk/<service directory>/<package>`). It can be a full link if this package is coming from somewhere else. A value of `NA` should be present if their is no go source link.
@@ -24,7 +24,7 @@ given package ecosystem as well as by reading release tags from our mono repos.
   - `spring` - This is a special classification only for Java that represents the spring libraries.
 - `New` - This field is set to true for any of our newer libraries that now following the guidelines outlined in this repo.
 - `PlannedVersions` - This field will list a set of versions combined with estimated dates in the format of `[version1],[date1]|[version2],[date2]|[version3],[date3]` with version in the format of `X.Y.Z[bN|-beta.N]` and date in the format of `MM/dd/yyyy`. These dates are intended to be displayed on a roadmap page.
-- `FirstGADate` - This field is used to identify the date of when a new package shipped its first GA.
+- `FirstGADate` - This field is used to identify the date of when a new package shipped its first stable release.
 - `Support` - This field is used to identify the level of support for the given package. See the [support guidelines](https://azure.github.io/azure-sdk/policies_support.html#package-lifecycle) for more details but this field should contain `active`, `maintenance`, `retired` or `community`, if the value is empty it generally implies unknown or `beta` support level.
 - `Hide` - This field will determine whether we hide this package from various places like the package index, docs, as well as automated updates. The value is either true to hide or empty to not hide. This is useful to filter older packages that are still on the package managers, but we don't want to promote or display anywhere.
 - `Replace` - This field is used the store the package name for the related older (replaces) or newer (replaced by) package. The value should be the exact name of the package (for java it should be `groupdid\artifactid`). If there are multiple then they should be separated by a comma (`,`).

eng/scripts/release-template/c.md

@@ -8,7 +8,7 @@ repository: Azure/azure-sdk-for-c
 
 The Azure SDK team is pleased to make available the %%MMMM yyyy%% client library release.
 
-#### GA
+#### Stable
 
 - _Add packages_