Removing hotfix vernacular from the examples

src/pages/docs/administration/retention-policies/retention-policy-tentacle-cleanup-and-troubleshooting.md

@@ -81,7 +81,7 @@ Learn more about [lifecycles](/docs/releases/lifecycles/) and [retention policie
 
 ## Retention policies with channels {#retention-policy-channels}
 
-[Channels](/docs/releases/channels) can be used in Octopus to handle many different deployment scenarios. In some cases you may have a hotfix channel in which deployments, as they are promoted through their environments, should be considered as overriding deployments from the default channel for the given environment. Alternatively you may be using channels to deploy feature branches which involve having several concurrent releases active at any one time across different channels for the same environment. When using the feature branch type scenario, you will likely want retention policies to recognize that since both channels should be accessible at the same time, the retention policy rules should apply to each independently. This behavior can be enabled for each project via the "Discrete Channel Releases" option on the **Project Settings** page.
+[Channels](/docs/releases/channels) can be used in Octopus to handle many different deployment scenarios. In some cases you may be using channels to deploy feature branches which involve having several concurrent releases active at any one time across different channels for the same environment. When using the feature branch type scenario, you will likely want retention policies to recognize that since both channels should be accessible at the same time, the retention policy rules should apply to each independently. This behavior can be enabled for each project via the "Discrete Channel Releases" option on the **Project Settings** page.
 
 :::figure
 ![Discrete Channel Release](/docs/img/administration/retention-policies/images/discrete-channel-release.png)

src/pages/docs/approvals/jira-service-management/index.md

@@ -217,7 +217,7 @@ Octopus supports matching a CR by setting the **Summary** of the CR to a well-kn
 
 `Octopus: Deploy "{project name}" version {release version number} to "{environment name}"`
 
-e.g `Octopus: Deploy "Web Site" version 1.0.1-hotfix-001 to "Dev"`
+e.g `Octopus: Deploy "Web Site" version 1.0.1-bugfix-001 to "Dev"`
 
 :::div{.hint}
 The title must match the format **exactly**, including the double-quotes.

src/pages/docs/approvals/servicenow/index.md

@@ -241,7 +241,7 @@ Octopus supports matching a CR by setting the **Short Description** of the CR to
 
 `Octopus: Deploy "{project name}" version {release version number} to "{environment name}"`
 
-e.g `Octopus: Deploy "Web Site" version 1.0.1-hotfix-001 to "Dev"`
+e.g `Octopus: Deploy "Web Site" version 1.0.1-bugfix-001 to "Dev"`
 
 :::div{.hint}
 The title must match the format **exactly**, including the double-quotes.

src/pages/docs/deployments/patterns/branching.md

@@ -53,7 +53,7 @@ Multiple release branches may be supported over a period of time. For example, y
 ![Multiple release branches supported at the same time](/docs/img/deployments/patterns/images/3278440.png)
 :::
 
-To prevent [retention policies](/docs/administration/retention-policies) for one channel from impacting deployments for another channel, version `3.12.2` introduces the [Discrete Channel Releases setting](/docs/releases/channels/#discrete-channel-releases). Enabling this feature will also ensure that your project overview dashboard correctly shows which releases are current for each environment *in each channel*. Without this set, the default behavior is for releases across channels to supersede each other (for example, in a hotfix scenario where the `3.2.2-bugfix` is expected to override the `3.2.2` release, allowing `3.2.2` to be considered for retention policy cleanup).
+To prevent [retention policies](/docs/administration/retention-policies) for one channel from impacting deployments for another channel, version `3.12.2` introduces the [Discrete Channel Releases setting](/docs/releases/channels/#discrete-channel-releases). Enabling this feature will also ensure that your project overview dashboard correctly shows which releases are current for each environment *in each channel*. Without this set, the default behavior is for releases across channels to supersede each other (for example, in a bugfix scenario where the `3.2.2-bugfix` is expected to override the `3.2.2` release, allowing `3.2.2` to be considered for retention policy cleanup).
 
  ![Discrete channel release](/docs/img/deployments/patterns/images/discrete-channel-release.png)
 

src/pages/docs/octopus-rest-api/cli/octopus-channel-delete.mdx

@@ -35,7 +35,7 @@ Global Flags:
 <SamplesInstance />
 
 ```bash
-octopus channel delete "Hotfix" --project myProject
+octopus channel delete "Default" --project myProject
 octopus channel rm Channels-123 --project myProject -y
 
 

src/pages/docs/octopus-rest-api/cli/octopus-channel-list.mdx

@@ -38,8 +38,8 @@ Global Flags:
 octopus channel list myProject
 octopus channel ls "Other Project"
 octopus channel list --project myProject
-octopus channel list --project myProject --filter "Hotfix"
-octopus channel ls -p myProject -q Hotfix
+octopus channel list --project myProject --filter "Default"
+octopus channel ls -p myProject -q Default
 
 
 ```

src/pages/docs/octopus-rest-api/cli/octopus-channel-view.mdx

@@ -32,7 +32,7 @@ Global Flags:
 <SamplesInstance />
 
 ```bash
-octopus channel view "Hotfix" --project myProject
+octopus channel view "Default" --project myProject
 octopus channel view Channels-123 --project myProject
 
 

src/pages/docs/octopus-rest-api/cli/octopus-channel.mdx

@@ -38,8 +38,8 @@ Use "octopus channel [command] --help" for more information about a command.
 ```bash
 octopus channel create
 octopus channel list --project myProject
-octopus channel view "Hotfix" --project myProject
-octopus channel delete "Hotfix" --project myProject
+octopus channel view "Default" --project myProject
+octopus channel delete "Default" --project myProject
 
 
 ```

src/pages/docs/packaging-applications/build-servers/codefresh-pipelines.md

@@ -401,11 +401,11 @@ create-release:
     OCTOPUS_URL: '${{OCTOPUS_URL}}'
     OCTOPUS_SPACE: "Default"
     PROJECT: "Project Name"
-    RELEASE_NUMBER: "1.0.0-hotfix1"
-    CHANNEL: "Hotfix"
+    RELEASE_NUMBER: "1.0.0"
+    CHANNEL: "Default"
     GIT_REF: "refs/heads/main"
     PACKAGES:
-      - "Sample:1.0.0-hotfix1"
+      - "Sample:1.0.0"
     RELEASE_NOTES: This is a release note
 ```
 

src/pages/docs/releases/channels/index.md

@@ -205,8 +205,8 @@ Branch and tag patterns used in Git protection rules support glob patterns and c
 
 | **Character** | **Description** | **Example** |
 | --- | --- | --- |
-| `*` | Matches multiple characters except `/` | Branch pattern of `release/*` will match branch `release/1.0.0` but not `release/1.0.0/hotfix1` |
-| `**` | Matches multiple characters including `/` | Branch pattern of `release/**` will match branch `release/1.0.0` and `release/1.0.0/hotfix1` |
+| `*` | Matches multiple characters except `/` | Branch pattern of `release/*` will match branch `release/1.0.0` but not `release/1.0.0/featureName` |
+| `**` | Matches multiple characters including `/` | Branch pattern of `release/**` will match branch `release/1.0.0` and `release/1.0.0/featureName` |
 | `?` | Matches a single character | Tag pattern of `v?` will match a tag of `v1` but not `v1.0.0` |
 | `[0-9]` | Matches a single character in the range | Tag pattern of `v[0-9].[0-9].[0-9]` will match a tag `v1.0.0` |
 | `[abc]` | Matches a single character from the set | Branch pattern of `release/[abc]*` will match branch `release/a-new-branch` but not `release/my-new-branch` |
@@ -317,7 +317,7 @@ In the following example, if version 3.1.0 of OctoFX is pushed to the built-in r
 
 ## Discrete channel releases {#discrete-channel-releases}
 
-The scenarios channels are used to model can be split into two categories. In the first, the channel controls the way releases are deployed (different lifecycles, deployment steps, etc), but the deployed releases should not be treated differently. An example of this would be a *Hotfix* channel, used to select a lifecycle designed to releases to production quickly.
+The scenarios channels are used to model can be split into two categories. In the first, the channel controls the way releases are deployed (different lifecycles, deployment steps, etc), but the deployed releases should not be treated differently. An example of this would be a *Ephemeral Environments* channel, used to select a lifecycle designed to deploy to Ephemeral Environments only.
 
 In the second mode of use, releases deployed via different channels are different, and should be treated as such. As an example of this, imagine a company that makes a deployment tool available as both a downloadable self-hosted product and a cloud-hosted software-as-a-service product.  In this example, the `self-hosted` and `cloud` channels not only select different lifecycles and deployment steps, but it is also desirable to view them as individual versions on the dashboard.
 

src/pages/docs/tasks/prioritize-tasks.md

@@ -17,13 +17,13 @@ From version `2025.2.7584`, the following features require an **Enterprise** tie
 
 ## Understanding task prioritization in Octopus
 
-When Octopus runs many deployments or runbooks at the same time, tasks are placed into a queue and processed in the order they were created. This can delay critical work, such as a production hotfix.  
+When Octopus runs many deployments or runbooks at the same time, tasks are placed into a queue and processed in the order they were created. This can delay critical work, such as a production bug fix.  
 
 To help with urgent or important jobs, Octopus provides three ways to control task priority:  
 
 1. **Task queue prioritization (Move to Top)**  
    - Best for unexpected, one-off situations.  
-   - Use this when you need to run a queued task immediately, such as a hotfix.
+   - Use this when you need to run a queued task immediately, such as a bug fix.
 
 2. **Priority deployments and runbooks**  
    - Best for proactive prioritization of important work.  
@@ -51,7 +51,7 @@ Within each category, tasks run on a **first in, first out** basis.
 
 From version `2023.4.6612`, you can manually move a queued task to the top of the queue.  
 
-This option is useful when you need to quickly prioritize a one-off task, such as a hotfix.
+This option is useful when you need to quickly prioritize a one-off task, such as a bug fix.
 
 You can prioritize tasks in two ways: