diff --git a/README.md b/README.md index e4b6cdb23b..cc5b023c4f 100644 --- a/README.md +++ b/README.md @@ -132,7 +132,7 @@ Check out [the CONTRIBUTING.md file](./CONTRIBUTING.md) for contribution guideli - Organise feature flags by [feature flag tags](https://docs.getunleash.io/reference/tags) - [Canary releases / gradual rollouts](https://docs.getunleash.io/reference/activation-strategies#gradual-rollout) - Targeted releases: release features to specific [users](https://docs.getunleash.io/reference/activation-strategies#userids), [IPs](https://docs.getunleash.io/reference/activation-strategies#ips), or [hostnames](https://docs.getunleash.io/reference/activation-strategies#hostnames) -- [Kill switches](https://docs.getunleash.io/reference/feature-toggle-types#feature-toggle-types) +- [Kill switches](https://docs.getunleash.io/reference/feature-toggles#feature-flag-types) - [A/B testing](https://docs.getunleash.io/feature-flag-tutorials/use-cases/a-b-testing) - 2 [environments](https://docs.getunleash.io/reference/environments) - Out-of-the-box integrations with popular tools ([Slack](https://docs.getunleash.io/addons/slack), [Microsoft Teams](https://docs.getunleash.io/addons/teams), [Datadog](https://docs.getunleash.io/addons/datadog)) + integrate with anything with [webhooks](https://docs.getunleash.io/addons/webhook) diff --git a/frontend/src/component/feature/Dependencies/DependenciesUpgradeAlert.tsx b/frontend/src/component/feature/Dependencies/DependenciesUpgradeAlert.tsx index 6fbe6bac4d..365fa96a1b 100644 --- a/frontend/src/component/feature/Dependencies/DependenciesUpgradeAlert.tsx +++ b/frontend/src/component/feature/Dependencies/DependenciesUpgradeAlert.tsx @@ -12,7 +12,7 @@ export const DependenciesUpgradeAlert = () => { const DependenciesDocsLink = () => { return ( diff --git a/frontend/src/component/feature/EditFeature/EditFeature.tsx b/frontend/src/component/feature/EditFeature/EditFeature.tsx index 77066c8190..d5cbfc12de 100644 --- a/frontend/src/component/feature/EditFeature/EditFeature.tsx +++ b/frontend/src/component/feature/EditFeature/EditFeature.tsx @@ -81,7 +81,7 @@ const EditFeature = () => { title='Edit Feature flag' description='Feature flags support different use cases, each with their own specific needs such as simple static routing or more complex routing. The feature flag is disabled when created and you decide when to enable' - documentationLink='https://docs.getunleash.io/reference/feature-toggle-types' + documentationLink='https://docs.getunleash.io/reference/feature-toggles#feature-flag-types' documentationLinkLabel='Feature flag types documentation' formatApiCode={formatApiCode} > diff --git a/frontend/src/component/featureTypes/FeatureTypeEdit/FeatureTypeForm/FeatureTypeForm.tsx b/frontend/src/component/featureTypes/FeatureTypeEdit/FeatureTypeForm/FeatureTypeForm.tsx index 8c874cb9a5..312867b5f3 100644 --- a/frontend/src/component/featureTypes/FeatureTypeEdit/FeatureTypeForm/FeatureTypeForm.tsx +++ b/frontend/src/component/featureTypes/FeatureTypeEdit/FeatureTypeForm/FeatureTypeForm.tsx @@ -125,7 +125,7 @@ export const FeatureTypeForm: VFC = ({ : `Edit flag type: ${featureType?.name}` } description={featureType?.description || ''} - documentationLink='https://docs.getunleash.io/reference/feature-toggle-types' + documentationLink='https://docs.getunleash.io/reference/feature-toggles#feature-flag-types' documentationLinkLabel='Feature flag types documentation' formatApiCode={formatApiCode} > @@ -151,7 +151,7 @@ export const FeatureTypeForm: VFC = ({


diff --git a/frontend/src/openapi/models/clientFeatureSchema.ts b/frontend/src/openapi/models/clientFeatureSchema.ts index dc10ae1f88..874b0d94fb 100644 --- a/frontend/src/openapi/models/clientFeatureSchema.ts +++ b/frontend/src/openapi/models/clientFeatureSchema.ts @@ -33,7 +33,7 @@ export interface ClientFeatureSchema { stale?: boolean; /** Evaluation strategies for this flag. Each entry in this list will be evaluated and ORed together */ strategies?: FeatureStrategySchema[]; - /** What kind of feature flag is this. Refer to the documentation on [feature flag types](https://docs.getunleash.io/reference/feature-toggle-types) for more information */ + /** What kind of feature flag is this. Refer to the documentation on [feature flag types](https://docs.getunleash.io/reference/feature-toggles#feature-flag-types) for more information */ type?: string; /** * [Variants](https://docs.getunleash.io/reference/feature-toggle-variants#what-are-variants) configured for this flag diff --git a/frontend/src/openapi/models/createFeatureSchema.ts b/frontend/src/openapi/models/createFeatureSchema.ts index b590a0a32b..75fe4c534f 100644 --- a/frontend/src/openapi/models/createFeatureSchema.ts +++ b/frontend/src/openapi/models/createFeatureSchema.ts @@ -21,6 +21,6 @@ export interface CreateFeatureSchema { name: string; /** Tags to add to the feature. */ tags?: TagSchema[]; - /** The feature flag's [type](https://docs.getunleash.io/reference/feature-toggle-types). One of experiment, kill-switch, release, operational, or permission */ + /** The feature flag's [type](https://docs.getunleash.io/reference/feature-toggles#feature-flag-types). One of experiment, kill-switch, release, operational, or permission */ type?: CreateFeatureSchemaType; } diff --git a/frontend/src/openapi/models/createFeatureSchemaType.ts b/frontend/src/openapi/models/createFeatureSchemaType.ts index b58bdd155a..0a96871e2c 100644 --- a/frontend/src/openapi/models/createFeatureSchemaType.ts +++ b/frontend/src/openapi/models/createFeatureSchemaType.ts @@ -5,7 +5,7 @@ */ /** - * The feature flag's [type](https://docs.getunleash.io/reference/feature-toggle-types). One of experiment, kill-switch, release, operational, or permission + * The feature flag's [type](https://docs.getunleash.io/reference/feature-toggles#feature-flag-types). One of experiment, kill-switch, release, operational, or permission */ export type CreateFeatureSchemaType = (typeof CreateFeatureSchemaType)[keyof typeof CreateFeatureSchemaType]; diff --git a/frontend/src/openapi/models/featureTypeSchema.ts b/frontend/src/openapi/models/featureTypeSchema.ts index 33931584f0..7d1ee7edb9 100644 --- a/frontend/src/openapi/models/featureTypeSchema.ts +++ b/frontend/src/openapi/models/featureTypeSchema.ts @@ -5,7 +5,7 @@ */ /** - * A [feature flag type](https://docs.getunleash.io/reference/feature-toggle-types). + * A [feature flag type](https://docs.getunleash.io/reference/feature-toggles#feature-flag-types. */ export interface FeatureTypeSchema { /** A description of what this feature flag type is intended to be used for. */ diff --git a/frontend/src/openapi/models/featureTypesSchema.ts b/frontend/src/openapi/models/featureTypesSchema.ts index c115abbed8..7d304840ce 100644 --- a/frontend/src/openapi/models/featureTypesSchema.ts +++ b/frontend/src/openapi/models/featureTypesSchema.ts @@ -7,7 +7,7 @@ import type { FeatureTypeSchema } from './featureTypeSchema'; import type { FeatureTypesSchemaVersion } from './featureTypesSchemaVersion'; /** - * A list of [feature flag types](https://docs.getunleash.io/reference/feature-toggle-types) and the schema version used to represent those feature types. + * A list of [feature flag types](https://docs.getunleash.io/reference/feature-toggles#feature-flag-types) and the schema version used to represent those feature types. */ export interface FeatureTypesSchema { /** The list of feature flag types. */ diff --git a/frontend/src/openapi/models/updateFeatureSchema.ts b/frontend/src/openapi/models/updateFeatureSchema.ts index 0b39a76d52..dfdbbabd50 100644 --- a/frontend/src/openapi/models/updateFeatureSchema.ts +++ b/frontend/src/openapi/models/updateFeatureSchema.ts @@ -9,7 +9,7 @@ import type { UpdateFeatureSchemaType } from './updateFeatureSchemaType'; * Data used for updating a feature flag */ export interface UpdateFeatureSchema { - /** If `true` the feature flag will be moved to the [archive](https://docs.getunleash.io/reference/archived-toggles) with a property `archivedAt` set to current time */ + /** If `true` the feature flag will be moved to the [archive](https://docs.getunleash.io/reference/feature-toggles#archive-a-feature-flag) with a property `archivedAt` set to current time */ archived?: boolean; /** Detailed description of the feature */ description?: string; diff --git a/frontend/src/openapi/models/updateFeatureTypeLifetimeSchema.ts b/frontend/src/openapi/models/updateFeatureTypeLifetimeSchema.ts index de0704f572..b264b3399e 100644 --- a/frontend/src/openapi/models/updateFeatureTypeLifetimeSchema.ts +++ b/frontend/src/openapi/models/updateFeatureTypeLifetimeSchema.ts @@ -5,7 +5,7 @@ */ /** - * Data used when updating the lifetime of a [feature flag type](https://docs.getunleash.io/reference/feature-toggle-types). + * Data used when updating the lifetime of a [feature flag type](https://docs.getunleash.io/reference/feature-toggles#feature-flag-types). */ export interface UpdateFeatureTypeLifetimeSchema { /** diff --git a/src/lib/features/feature-toggle/archive-feature-toggle-controller.ts b/src/lib/features/feature-toggle/archive-feature-toggle-controller.ts index 7fb5135953..039d279a6f 100644 --- a/src/lib/features/feature-toggle/archive-feature-toggle-controller.ts +++ b/src/lib/features/feature-toggle/archive-feature-toggle-controller.ts @@ -64,7 +64,7 @@ export default class ArchiveController extends Controller { tags: ['Archive'], summary: 'Get archived features', description: - 'Retrieve a list of all [archived feature flags](https://docs.getunleash.io/reference/archived-toggles).', + 'Retrieve a list of all [archived feature flags](https://docs.getunleash.io/reference/feature-toggles#archive-a-feature-flag).', operationId: 'getArchivedFeatures', responses: { 200: createResponseSchema('archivedFeaturesSchema'), diff --git a/src/lib/openapi/spec/client-feature-schema.ts b/src/lib/openapi/spec/client-feature-schema.ts index 981b4e81eb..93024659c5 100644 --- a/src/lib/openapi/spec/client-feature-schema.ts +++ b/src/lib/openapi/spec/client-feature-schema.ts @@ -24,7 +24,7 @@ export const clientFeatureSchema = { type: { type: 'string', description: - 'What kind of feature flag is this. Refer to the documentation on [feature flag types](https://docs.getunleash.io/reference/feature-toggle-types) for more information', + 'What kind of feature flag is this. Refer to the documentation on [feature flag types](https://docs.getunleash.io/reference/feature-toggles#feature-flag-types) for more information', example: 'release', }, description: { diff --git a/src/lib/openapi/spec/create-feature-schema.ts b/src/lib/openapi/spec/create-feature-schema.ts index 9b21d10264..f8e34ff8ee 100644 --- a/src/lib/openapi/spec/create-feature-schema.ts +++ b/src/lib/openapi/spec/create-feature-schema.ts @@ -22,7 +22,7 @@ export const createFeatureSchema = { ], example: 'release', description: - "The feature flag's [type](https://docs.getunleash.io/reference/feature-toggle-types). One of experiment, kill-switch, release, operational, or permission", + "The feature flag's [type](https://docs.getunleash.io/reference/feature-toggles#feature-flag-types). One of experiment, kill-switch, release, operational, or permission", }, description: { type: 'string', diff --git a/src/lib/openapi/spec/feature-type-schema.ts b/src/lib/openapi/spec/feature-type-schema.ts index 504bba72aa..49bb08d193 100644 --- a/src/lib/openapi/spec/feature-type-schema.ts +++ b/src/lib/openapi/spec/feature-type-schema.ts @@ -4,7 +4,7 @@ export const featureTypeSchema = { $id: '#/components/schemas/featureTypeSchema', type: 'object', description: - 'A [feature flag type](https://docs.getunleash.io/reference/feature-toggle-types).', + 'A [feature flag type](https://docs.getunleash.io/reference/feature-toggles#feature-flag-types).', additionalProperties: false, required: ['id', 'name', 'description', 'lifetimeDays'], properties: { diff --git a/src/lib/openapi/spec/feature-types-schema.ts b/src/lib/openapi/spec/feature-types-schema.ts index 9fa17d9069..88c12e43ed 100644 --- a/src/lib/openapi/spec/feature-types-schema.ts +++ b/src/lib/openapi/spec/feature-types-schema.ts @@ -6,7 +6,7 @@ export const featureTypesSchema = { type: 'object', additionalProperties: false, description: - 'A list of [feature flag types](https://docs.getunleash.io/reference/feature-toggle-types) and the schema version used to represent those feature types.', + 'A list of [feature flag types](https://docs.getunleash.io/reference/feature-toggles#feature-flag-types) and the schema version used to represent those feature types.', required: ['version', 'types'], properties: { version: { diff --git a/src/lib/openapi/spec/update-feature-schema.ts b/src/lib/openapi/spec/update-feature-schema.ts index ecaae0f9f7..a379b83eff 100644 --- a/src/lib/openapi/spec/update-feature-schema.ts +++ b/src/lib/openapi/spec/update-feature-schema.ts @@ -33,7 +33,7 @@ export const updateFeatureSchema = { type: 'boolean', example: true, description: - 'If `true` the feature flag will be moved to the [archive](https://docs.getunleash.io/reference/archived-toggles) with a property `archivedAt` set to current time', + 'If `true` the feature flag will be moved to the [archive](https://docs.getunleash.io/reference/feature-toggles#archive-a-feature-flag) with a property `archivedAt` set to current time', }, impressionData: { type: 'boolean', diff --git a/src/lib/openapi/spec/update-feature-type-lifetime-schema.ts b/src/lib/openapi/spec/update-feature-type-lifetime-schema.ts index ecdf4aee70..8b2a142e9b 100644 --- a/src/lib/openapi/spec/update-feature-type-lifetime-schema.ts +++ b/src/lib/openapi/spec/update-feature-type-lifetime-schema.ts @@ -5,7 +5,7 @@ export const updateFeatureTypeLifetimeSchema = { type: 'object', required: ['lifetimeDays'], description: - 'Data used when updating the lifetime of a [feature flag type](https://docs.getunleash.io/reference/feature-toggle-types).', + 'Data used when updating the lifetime of a [feature flag type](https://docs.getunleash.io/reference/feature-toggles#feature-flag-types).', properties: { lifetimeDays: { description: diff --git a/src/lib/openapi/util/openapi-tags.ts b/src/lib/openapi/util/openapi-tags.ts index 683d43eb63..a976d8c653 100644 --- a/src/lib/openapi/util/openapi-tags.ts +++ b/src/lib/openapi/util/openapi-tags.ts @@ -58,7 +58,7 @@ const OPENAPI_TAGS = [ { name: 'Feature Types', description: - 'Manage [feature flag types](https://docs.getunleash.io/reference/feature-toggle-types).', + 'Manage [feature flag types](https://docs.getunleash.io/reference/feature-toggles#feature-flag-types).', }, { name: 'Features', diff --git a/src/lib/routes/admin-api/feature-type.ts b/src/lib/routes/admin-api/feature-type.ts index 189dfbf2aa..46b20ff447 100644 --- a/src/lib/routes/admin-api/feature-type.ts +++ b/src/lib/routes/admin-api/feature-type.ts @@ -75,7 +75,7 @@ export class FeatureTypeController extends Controller { tags: ['Feature Types'], operationId: 'updateFeatureTypeLifetime', summary: 'Update feature type lifetime', - description: `Updates the lifetime configuration for the specified [feature flag type](https://docs.getunleash.io/reference/feature-toggle-types). The expected lifetime is an integer representing the number of days before Unleash marks a feature flag of that type as potentially stale. If set to \`null\` or \`0\`, then feature flags of that particular type will never be marked as potentially stale. + description: `Updates the lifetime configuration for the specified [feature flag type](https://docs.getunleash.io/reference/feature-toggles#feature-flag-types). The expected lifetime is an integer representing the number of days before Unleash marks a feature flag of that type as potentially stale. If set to \`null\` or \`0\`, then feature flags of that particular type will never be marked as potentially stale. When a feature flag type's expected lifetime is changed, this will also cause any feature flags of this type to be reevaluated for potential staleness.`, responses: { diff --git a/website/docs/feature-flag-tutorials/use-cases/a-b-testing.md b/website/docs/feature-flag-tutorials/use-cases/a-b-testing.md index e466f38df2..f929272667 100644 --- a/website/docs/feature-flag-tutorials/use-cases/a-b-testing.md +++ b/website/docs/feature-flag-tutorials/use-cases/a-b-testing.md @@ -23,7 +23,7 @@ In the projects view, the Unleash platform shows a list of feature flags that yo Next, you will create a feature flag on the platform and turn it on for your app. -Flags can be used with different purposes and we consider experimentation important enough to have its own flag type. Experimentation flags have a lifetime expectancy suited to let you run an experiment and gather enough data to know whether it was a success or not. Learn more about [feature flag types](/reference/feature-toggle-types) in our documentation. +Flags can be used with different purposes and we consider experimentation important enough to have its own flag type. Experimentation flags have a lifetime expectancy suited to let you run an experiment and gather enough data to know whether it was a success or not. Learn more about [feature flag types](/reference/feature-toggles#feature-flag-types) in our documentation. The feature flag we are creating is considered an ‘Experimentation’ flag type. The project will be ‘Default’ or the named project in which you are working in for the purpose of this tutorial. As the number of feature flags grows, you can organize them in your projects. diff --git a/website/docs/how-to/how-to-add-feature-flag-naming-patterns.mdx b/website/docs/how-to/how-to-add-feature-flag-naming-patterns.mdx deleted file mode 100644 index 7bb75709f7..0000000000 --- a/website/docs/how-to/how-to-add-feature-flag-naming-patterns.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: How to add feature flag naming patterns ---- - -:::note Availability - -**Plan**: [Enterprise](https://www.getunleash.io/pricing) | **Version**: `5.7`+ - -::: - -This short guide will show you how to add [feature flag naming patterns](../reference/feature-flag-naming-patterns.mdx) to a project. - -## Prerequisites - -- You must be using an Unleash Enterprise instance. -- You must have permissions to edit project settings for the project you want to add feature flag naming patterns to. - -## Step 1: Navigate to project settings - -Navigate to the project settings page for the project you want to add feature flag naming patterns to. - -## Step 2: Add a feature flag naming pattern - -Use the "feature flag naming pattern" section of the project settings form to add a feature flag naming pattern, plus the optional example and/or description. - -When you've entered your data, save the changes. - -![The "feature flag naming pattern" part of the form. Input fields for pattern, example, and description](/img/naming-pattern-forms.png) diff --git a/website/docs/how-to/how-to-environment-import-export.mdx b/website/docs/how-to/how-to-environment-import-export.mdx index c1df68fe55..5eeb565fa8 100644 --- a/website/docs/how-to/how-to-environment-import-export.mdx +++ b/website/docs/how-to/how-to-environment-import-export.mdx @@ -26,7 +26,7 @@ On the project-level these items are exported: * [the feature itself](/reference/feature-toggles.mdx) * [feature tags](/reference/tags.md) -* [feature dependencies](/reference/dependent-features.md) +* [feature dependencies](/reference/feature-toggles#feature-flag-dependencies) On the environment-level, these items are exported for the chosen environment: diff --git a/website/docs/reference/api/legacy/unleash/admin/features-v2.md b/website/docs/reference/api/legacy/unleash/admin/features-v2.md index f208a0dab7..6671c000fa 100644 --- a/website/docs/reference/api/legacy/unleash/admin/features-v2.md +++ b/website/docs/reference/api/legacy/unleash/admin/features-v2.md @@ -172,7 +172,7 @@ This endpoint accepts the following flag options: | `name` | Yes | The name of the feature flag. | `"my-feature-flag"` | | `description` | No | The feature flag's description. Defaults to an empty string. | `"Turn my feature on!"` | | `impressionData` | No | Whether to enable [impression data](/reference/impression-data.md) for this flag. Defaults to `false.` | `true` | -| `type` | No | The [type of flag](/reference/feature-toggle-types.md) you want to create. Defaults to `"release"` | `"release"` | +| `type` | No | The [type of flag](/reference/feature-toggles#feature-flag-types) you want to create. Defaults to `"release"` | `"release"` | **Example Query** diff --git a/website/docs/reference/archived-toggles.md b/website/docs/reference/archived-toggles.md deleted file mode 100644 index 747855fe96..0000000000 --- a/website/docs/reference/archived-toggles.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Archived Flags ---- - -You can _archive_ a feature flag when it is not needed anymore. You do this by clicking the "Archive" button on the feature flag details view. When you archive a feature flag, it will no longer be available to Client SDKs. - -![The Unleash flag view showing a focused "archive feature flag" button, highlighted by a red arrow.](/img/archive-toggle.png 'Archiving a Feature Flag') - -## Viewing archived flags - -Archived flags are displayed in two places: - -1. The global flag archive -2. The containing project's flag archive - -Unleash keeps a list of _all_ archived flags across projects in the _global archive_. The global archive is accessible from the global feature list. - -Additionally, each project keeps a list of all of _its_ archived flags. That is, when you archive a flag, Unleash adds it to the containing project's archive. - -## Reviving a feature flag {#reviving-a-feature-toggle} - -If you want to re-use a feature flag that you previously archived, you can revive in from the feature flag archive. Click the "revive icon" to revive the flag. Revived flags will be in the disabled state when you re-enable them. - -![A list of archived flags. Each flag displays its name and project it belongs to. Each flag also has a "revive" button, as highlighted by a red arrow.](/img/archive-toggle-revive.png 'Reviving a Feature Flag') - -## Deleting a feature flag - -:::caution - -We generally discourage deleting feature flags. The reason is that feature flag names in Unleash are used as identifiers, so if you were to delete a flag and then create a new one with the same name, the new one would reactivate any code that uses the old flag. - -::: - -The only way to fully _delete_ a feature flag in Unleash is by using the archive. An archived flag can be deleted via the API or by using the "delete feature flag" button in the global or project-level archive. - -![A list of archived flags, each with a button to delete the flag permanently.](/img/archive-toggle-delete.png) diff --git a/website/docs/reference/dependent-features.md b/website/docs/reference/dependent-features.md deleted file mode 100644 index dddcb13157..0000000000 --- a/website/docs/reference/dependent-features.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: Dependent Features ---- - -:::note Availability - -**Plan**: [Pro](https://www.getunleash.io/pricing) and [Enterprise](https://www.getunleash.io/pricing) | **Version**: `5.7+` - -::: - -## Overview - -Dependent features allow to define a child feature flag that depends on a parent feature flag. -A feature flag can have only one parent dependency but multiple child flags can share the same parent. For a child flag to be activated, its parent dependency must be satisfied. - -## Parent dependency criteria - -* **Project Association**: Both parent and child flags should belong to the same project. -* **Single Level Dependency**: The parent flag can’t have its own parent, ensuring a straightforward, single-level dependency. -* **Parent Value**: Parent value should match predefined feature status and variant criteria. - -### Parent value criteria - -In order for the child feature to be evaluated, the corresponding parent value criteria must be satisfied. - -Parent value criteria can be set to one of the 3 options: -- Parent feature must be **enabled**. -- Parent feature must be **disabled**. This is useful when your parent is a [kill-switch](./feature-toggle-types.md#feature-toggle-types) with the inverted enabled/disabled logic. -- Parent feature must be **enabled with variants**. This is useful when your parent is part of A/B testing, and you need [variant dependencies](#variant-dependencies). - -#### Variant dependencies - -:::note Availability - -**Plan**: [Pro](https://www.getunleash.io/pricing) and [Enterprise](https://www.getunleash.io/pricing) | **Version**: `5.12+` - -::: - -For the variant dependencies, if the parent feature variant is evaluated to the expected value, the dependency is satisfied. You can specify variant values from all [strategy variants](./strategy-variants.md) and all [feature environment variants](./feature-toggle-variants.md). The parent dependency variant is compared to the actual value that the parent dependency is evaluated to in a given environment. - -Consult [strategy variants order](./strategy-variants.md#strategy-variants-and-strategies-order) and [variants comparison](./strategy-variants#strategy-variants-vs-feature-flag-variants) sections for more details on the variant evaluation order. - -## Managing dependencies - -### Adding - -Introduce dependencies either through the UI or API, also applicable when copying a child feature with an existing parent dependency. - -![A button for adding parent dependency.](/img/add-parent-dependency.png 'Adding a new parent feature dependency') - -### Removing - -Eliminate them through the UI or API. Dependencies are also removed when archiving a child feature. A parent feature can’t be removed if it would leave a child feature orphaned. To remove both, batch archive them. If Unleash confirms no other child features are using the parent, archiving proceeds. - -![A button for deleting parent dependency.](/img/delete-parent-dependency.png 'Depeting a parent feature dependency') - - -## Permissions - -The **Update feature dependency** project permission, auto-assigned to admin and project members, allows managing dependencies. - -## Metrics calculation - -Metrics are influenced solely by the evaluation of child features. - -## Client SDK Support {#client-sdk-support} - -To make use of dependent feature, you need to use a compatible client. Client SDK with variant support: - -- [unleash-client-node](https://github.com/Unleash/unleash-client-node) (from v4.2.0) -- [unleash-client-java](https://github.com/Unleash/unleash-client-java) (from v8.4.0) -- [unleash-client-go](https://github.com/Unleash/unleash-client-go) (from v3.9.2) -- [unleash-client-python](https://github.com/Unleash/unleash-client-python) (from v5.9.0) -- [unleash-client-ruby](https://github.com/Unleash/unleash-client-ruby) (from v4.6.0) -- [unleash-client-dotnet](https://github.com/Unleash/unleash-client-dotnet) (from v3.4.0) -- [unleash-client-php](https://github.com/Unleash/unleash-client-php) (from v2.2.0) -- Client SDKs talking to [unleash-proxy](https://github.com/Unleash/unleash-proxy) (from v0.18.0) -- Client SDKs talking to [unleash-edge](https://github.com/Unleash/unleash-edge) (from v13.1.0) -- Client SDKs talking to Frontend API in [unleash-server](https://github.com/Unleash/unleash) (from v5.7.0) -- Unleash Playground in [unleash-server](https://github.com/Unleash/unleash) (from v5.7.0) - - -If you would like to give feedback on this feature, experience issues or have questions, please feel free to open an issue on [GitHub](https://github.com/Unleash/unleash/). diff --git a/website/docs/reference/events.mdx b/website/docs/reference/events.mdx index 772b4a5407..75323f633a 100644 --- a/website/docs/reference/events.mdx +++ b/website/docs/reference/events.mdx @@ -291,7 +291,7 @@ Generated when you drop all existing tags as part of a configuration import. The #### `feature-potentially-stale-on` -Generated when Unleash marks a feature flag as potentially stale due to exceeding the expected lifetime of its [feature flag type](/reference/feature-toggle-types). `preData` and `data` are null. +Generated when Unleash marks a feature flag as potentially stale due to exceeding the expected lifetime of its [feature flag type](/reference/feature-toggles#feature-flag-types). `preData` and `data` are null. #### `feature-updated` diff --git a/website/docs/reference/feature-flag-naming-patterns.mdx b/website/docs/reference/feature-flag-naming-patterns.mdx deleted file mode 100644 index 03da142f21..0000000000 --- a/website/docs/reference/feature-flag-naming-patterns.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: Feature Flag Naming Patterns ---- - -:::note Availability - -**Plan**: [Enterprise](https://www.getunleash.io/pricing) | **Version**: `5.7+` - -::: - -A feature flag naming pattern is [JavaScript regular expression](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp) that is used to validate the name of a feature flag before the flag can be created. - -The pattern is defined in the project settings and is enforced when creating a new feature flag. The pattern is also enforced when creating a new feature flag via the API. - -Patterns are implicitly anchored to the start and end of the string. This means that a pattern is matched against the entire new feature flag name, and not just any subset of it, as if the pattern was surrounded by `^` and `$`. In other words, the pattern `[a-z]+` will be interpreted as `^[a-z]+$` and will match "somefeature", but will not match "some.other.feature". - -Feature flag naming patterns are defined on a per-project basis. - -In addition to the pattern itself, you can also define an example and a description of the pattern. If defined, both the example and the description will be shown to the user when they are creating a new feature flag. - -## Overview - -The naming pattern consists of three parts: - -
-
Pattern (required)
-
The regular expression that is used to validate the name of the feature flag. Must be a valid regular expression. Flags (such as case insensitivity) are not available.
-
Example (optional)
-
An example of a name that is valid according to the provided pattern. Note: the example must be valid against the described pattern for it to be saved.
-
Description (optional)
-
Any additional text that you would like to display to users to provide extra information. This can be anything that you think they would find useful and can be as long or short as you want.
-
- -For instance, you might define a pattern that requires all feature flags to follow a specific pattern, such as `^(red|blue|green|yellow)\.[a-z-]+\.[0-9]+$`. You could then provide an example of a valid feature flag name (for instance "blue.water-gun.64") and a description of what the pattern should reflect: "`..`". diff --git a/website/docs/reference/feature-lifecycle.md b/website/docs/reference/feature-lifecycle.md deleted file mode 100644 index c1a2a1a021..0000000000 --- a/website/docs/reference/feature-lifecycle.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: Feature Lifecycle ---- - -:::note Availability - -**Version**: `6.2+` - -::: - -![Feature Lifecycle example](/img/feature-lifecycle.png 'Feature Lifecycle example') - -In Unleash, the feature lifecycle encompasses a holistic view of how mature your feature is based on data collected through metrics and interactions with the Unleash system. -As such, the lifecycle mirrors your software development process and allows you to identify bottlenecks at any stage of the lifecycle. -These findings may give you insights or clues to improve the efficiency of your software development process. Read more about how Unleash progresses a feature through the lifecycle below. - -## Lifecycle stages - -Each stage in the lifecycle has a defined purpose: - -### Initial stage - -The feature flag is created but remains unseen in any environment. - -**Purpose:** marks the initiation of the feature. - -### Pre-live stage - -The feature flag has received metrics in non-production environment or has received metrics in a disabled production environment. - -**Purpose:** testing and validating the feature before it goes live. - -### Live stage - -The feature has received metrics in the enabled production environment. -Once enough has been learned about the feature from production usage, you can mark the feature as completed. -When marking a feature as complete, you decide whether to keep the feature, discard it, or keep one variant of the feature. -This information can be used by code cleanup tools to automate feature removal from your code. - -**Purpose:** testing and validating the feature in production and marking feature completion. - -### Completed stage - -The feature's objectives have been achieved, and it is ready to be phased out. -The lifecycle feature warns you if a completed feature continues to receive traffic, signaling that it hasn't been fully removed from the code. -If you've accidentally marked the feature as completed, you can always revert it to the live stage. - -**Purpose:** initiating cleanup processes and signalling when it's safe to archive a feature. - -### Archived stage - -The feature is archived in Unleash and can be deleted. If an archived feature is revived, it starts a new lifecycle with a new initial stage. - -**Purpose:** reducing technical debt by removing obsolete features. - -## Lifecycle stages and process improvement - -Understanding how much time a feature spends in each stage can highlight inefficiencies: -* **Stuck in Initial**: May indicate integration issues in pre-production setups. -* **Stuck in Pre-live**: Suggests challenges in achieving production readiness. -* **Stuck in Live**: Could imply difficulties in data gathering or decision-making regarding the feature’s future. -* **Stuck in Completed**: Indicates delays in decommissioning the feature and cleaning up resources. diff --git a/website/docs/reference/feature-toggle-types.md b/website/docs/reference/feature-toggle-types.md deleted file mode 100644 index b7727bd79e..0000000000 --- a/website/docs/reference/feature-toggle-types.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: Feature Flag Types ---- - -:::note Availability - -**Version**: `3.5+` - -::: - - -You can use feature flags to support different use cases, each with their own specific needs. Heavily inspired by [Pete Hodgson's article on feature flags](https://martinfowler.com/articles/feature-toggles.html), Unleash introduced the concept of feature flag types in version `3.5.0`. - -A feature flag's type affects only two things: -1. It gives the flag an appropriate icon -2. The flag's expected lifetime changes - -Aside from this, there are no differences between the flag types and you can always change the type of a flag after you have created it. - -Classifying feature flags by their type makes it easier for you manage them: the flags get different icons in the flag list and you can sort the flags by their types. - -![Five feature flags, each of a different type, showing the different icons that Unleash uses for each flag type.](/img/toggle_type_icons.png "Feature flag type icons") - -A flag's type also helps Unleash understand the [flag's expected lifetime](#expected-lifetimes). -## Feature flag types - -Here's the list of the feature flag types that Unleash supports together with their intended use case and expected lifetime: - -| Feature flag type | Used to ... | Expected lifetime | -|---------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------| -| Release | Enable trunk-based development for teams practicing Continuous Delivery. | 40 days | -| Experiment | Perform multivariate or A/B testing. | 40 days | -| Operational | Control operational aspects of the system's behavior. | 7 days | -| Kill switch | Gracefully degrade system functionality. You can read about [kill switch best practices](https://www.getunleash.io/blog/kill-switches-best-practice) on our blog. | Permanent | -| Permission | Change the features or product experience that certain users receive. | Permanent | - -### Expected lifetimes - -:::info - -The ability to update a feature flag type's expected lifetime is currently in development. We expect to release it in one of the upcoming releases. - -::: - -A feature flag's expected lifetime is an indicator of how long Unleash expects flags of that type to be around. Some feature flags are meant to live for a few weeks as you work on new functionality, while others stick around for much longer. As a part of good code hygiene, you should clean up your feature flags when they have served their purpose. This is further explored in the document on [technical debt](technical-debt.md). - -Each feature flag type in Unleash has an assigned expected lifetime, after which the system will consider this feature _potentially stale_. The reasoning behind each type's expected lifetime is detailed in this [blog post on best practices for feature flag lifetimes](https://www.getunleash.io/blog/feature-toggle-life-time-best-practices). - -Unleash admins can change the expected lifetime of Unleash's feature types from the Unleash configuration menu. - - -## Deprecating feature flags {#deprecate-a-feature-toggle} - -You can mark feature flags as `stale`. This is a way to deprecate a feature flag without removing the active configuration for connected applications. Use this to signal that you should stop using the feature in your applications. Stale flags will show as stale in the ["technical debt dashboard"](technical-debt.md). - -When you mark a flag as stale, Unleash will emit an event. You can use [an integration](integrations/integrations.md) to integrate this with your systems, for instance to post a message in a Slack channel. - -Additionally, with some extra work, you can also use the `stale` property to: - -- Inform developers that a flag is stale _while_ they're developing. -- Break a project build if the code contains stale feature flags. -- Send automatic PRs to remove usage of flags that have served their purpose. diff --git a/website/docs/reference/feature-toggles.mdx b/website/docs/reference/feature-toggles.mdx index 4b12e861dd..a3bfe2ae66 100644 --- a/website/docs/reference/feature-toggles.mdx +++ b/website/docs/reference/feature-toggles.mdx @@ -2,38 +2,199 @@ title: Feature Flags --- -Feature flags are the central concept that we built Unleash around. In Unleash, feature flags are organized within [projects](../reference/projects.md). Feature flags can have different [activation strategies](../reference/activation-strategies.md) for each of their project's [environments](../reference/environments.md), and can also be given [variants](../reference/feature-toggle-variants.md) to facilitate A/B testing. +## Overview -## Configuration options +Feature flags are a core concept of Unleash. They allow you to release, test, and manage features and functionality across your application without changing the source code. -Each feature flag has the following configuration options +Feature flags exist within a [project](./projects) and have distinct configurations and [activation strategies](./activation-strategies) for each of the project's active [environments](./environments). Activation strategies determine whether a feature flag is enabled in a specific environment. -| Option | Required? | Default value | Description | -| --- | --- | --- | --- | -| name | Yes | N/A | The feature flag's name. Must be URL-friendly according to [section 2.3 of RFC 3986](https://www.rfc-editor.org/rfc/rfc3986#section-2.3) and must be unique within your Unleash instance. Must be between 1 and 100 characters long, inclusive. | -| feature flag type | Yes | Release | The [feature flag's type](../reference/feature-toggle-types.md). | -| project | Yes | The [default project](../reference/projects.md). When created from a project page in the admin UI, that project will be the default value instead. | The [project](../reference/projects.md) that should contain the feature flag. | -| description | No | N/A | A description of the feature flag's purpose. | -| enable impression data | Yes | No | Whether to enable [impression data](../reference/impression-data.md) for this flag or not. | +Feature flags have the following properties: -## Environments +- **Name**: A [URL-friendly](https://www.rfc-editor.org/rfc/rfc3986#section-2.3) string between 1 and 100 characters; must be unique per instance. +- **Type**: The [feature flag's type](#feature-flag-types); defaults to `Release`. +- **Project**: The [project](./projects) that contains the feature flag. +- **Description**: An optional description of the feature flag's purpose. +- **Impression data**: Indicates whether impression data is enabled for the flag; disabled by default. -You probably won't want to use the same configuration to enable a flag in development as you do in production. That's why feature flags have different activation strategy configurations for each environment. +## Environments and activation strategies -You can enable and disable a flag independently in each of the [project's environments](../reference/projects.md). When you disable a flag in an environment, it will always evaluate to false in that environment. When you enable a flag in an environment, the flag will evaluate to true or false depending on its activation strategies. +Feature flags have different [activation strategies](./activation-strategies) for each environment, allowing you to manage feature rollouts per environment. -Refer to the [documentation on environments](../reference/environments.md) for more details on how environments work. +To activate a feature within an environment, assign at least one activation strategy to it. If you don't specify a strategy, the default is a gradual rollout to 100%. -## Activation strategies +Activation strategies determine whether a feature flag activates for a specific [Unleash context](./unleash-context), such as a particular user or segment. When multiple strategies are in place, the flag activates if any one of the strategies evaluates to true. -To enable a feature in an environment, you must assign it at least one activation strategy. A feature flag's activation strategies determine whether the flag gets enabled for a particular [Unleash context](../reference/unleash-context.md) (typically a user). When using multiple strategies in a single environment, only a single strategy needs to evaluate to true for the flag to get enabled for a user. Whenever Unleash evaluates a flag, it will evaluate strategies in the current environment until one of them resolves to true. If no strategies resolve to true, then the flag's value is false. +### Strategy variants -Refer to the [activation strategies documentation](../reference/activation-strategies.md) for a detailed description of all the built-in strategies. +You can enhance your feature flags with [strategy variants](./strategy-variants.md). Feature flags let you define who gets access to a feature. With variants, you can also determine which version of the feature they see. +For example, you might use variants to run an A/B testing experiment. -## Variants +Variants are defined by a name and weight, which determines the likelihood of each variant being shown. [Stickiness](./stickiness) ensures that users consistently see the same variant based on predefined parameters. +Variants can also include payloads such as JSON, CSV, or strings to provide users with additional context. -[Variants](../reference/feature-toggle-variants.md) adds another dimension of flexibility to feature flags. Each feature flag can be assigned any number of variants which will then get distributed amongst your users based on your choice of [context field](../reference/unleash-context.md#structure). You can find out more about variants in the [variants docs](../reference/feature-toggle-variants.md). -### Creating flags with payloads +## Feature flag types + +:::note Availability + +**Version**: `3.5+` + +::: + + +Feature flags have a type to indicate their use case and help you manage and sort your flags. A feature flag's type determines its [expected lifetime](#expected-lifetime) and its visual appearance in the Admin UI. + + +The following is a list of feature flag types: + +| Feature flag type | Used to | Expected lifetime | +|---------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------| +| Release | Manage the deployment of new or incomplete features. | 40 days | +| Experiment | Perform multivariate or A/B testing. | 40 days | +| Operational | Transition between technical implementations with minimal risk. | 7 days | +| Kill switch | Gracefully degrade system functionality. | Permanent | +| Permission | Control feature access based on user roles or entitlements. | Permanent | + +To learn more, visit [Types of feature flags](../what-is-a-feature-flag#types-of-feature-flags). + +## Feature flag state + +A feature flag can have one of the following states: _active_, _potentially stale_, or _stale_. Unleash marks all flags as _potentially stale_ automatically once they pass their [expected lifetime](#expected-lifetime). + +State gives you an indication of when to [clean up a feature flag in code](./technical-debt.md). + +You can also manually change the state on a feature flag's page by going to **Overview** and clicking **Toggle stale state**. + +![Marking a feature flag as stale](/img/mark-flag-stale.png) + +Marking a flag as stale helps you deprecate a feature flag without removing the active configuration for connected applications. + +You can use this to signal to your team to stop using the feature in your applications. Stale flags will show as stale in the [technical debt dashboard](./technical-debt). + +Marking a flag as stale generates the `feature-stale-on` [event](./reference/events#feature-stale-on). You can use [an integration](/integrations/integrations) to trigger automated workflows, such as posting notifications in a Slack channel, breaking project builds if the code contains stale flags, or automatically opening pull requests to remove stale flags from the code. + +### Configure expected lifetime + +Each [feature flag type](#feature-flag-type) has a default expected lifetime. +With Admin access, you can configure these values. In the Admin UI, go to **Configure > Feature flag types** and edit the flag type you'd like to change. + +## Feature flag lifecycle + +:::note Availability + +**Version**: `6.2+` + +::: + +Based on usage metrics and interactions with Unleash, feature flags can go through five distinct lifecycle stages: initial, pre-live, live, completed, and archived. These stages mirror the typical software development process and allow you to identify bottlenecks at any stage of the lifecycle. +These insights can help you improve the efficiency of your software development process. + +![Feature lifecycle](/img/feature-lifecycle.png) + +### Lifecycle stages + +#### Initial + +The feature flag is created, but Unleash hasn't detected any metrics in any environments. Once Unleash receives metrics from a non-production environment, the flag moves to the [pre-live](#pre-live) stage. + +A feature stuck in an initial stage can indicate integration issues in pre-production setups. + +#### Pre-live + +The feature flag has received metrics in a non-production environment or a production environment that is disabled. Too much time in the pre-live stage can suggest challenges in achieving production readiness. + +#### Live + +The first users have been exposed to the feature in a production environment. Once you have enough production usage data, you can mark the feature as completed. Marking the feature flag as complete does not affect any configuration; you decide whether to keep the feature, keep just one variant of it, or archive it entirely. + +This stage serves as a reminder to start cleaning up the feature toggle and removing it from the code. A feature flag stuck in the live stage can indicate difficulties in data gathering or decision-making. + +#### Completed + +The feature has been completed but Unleash still receives usage metrics in production. This is an indication that you should clean up the feature flag from your code before archiving it. +If you've accidentally marked the feature as completed, you can revert it to the [live](#live) stage. + +Too much time in the completed stage can indicate delays in decommissioning the feature and cleaning up resources. + +#### Archived + +Unleash hasn't detected any production usage metrics for at least two days. It's likely that it is safe to archive this flag. +If an archived feature is revived, it starts a new lifecycle with a new [initial](#initial) stage. + +## Feature flag dependencies + +:::note Availability + +**Plan**: [Pro](https://www.getunleash.io/pricing) and [Enterprise](https://www.getunleash.io/pricing) + +**Unleash version**: `5.7+` | **Unleash Edge version**: `13.1+` | **Unleash Proxy version**: `0.18+`. Requires [SDK compatibility](../reference/sdks/index.md#server-side-sdk-compatibility-table) for variants. +::: + +Feature flag dependencies define a relationship between feature flags. Each feature flag can have one parent, but multiple child flags can share the same parent. +The hierarchy is limited to a single level, meaning a parent flag cannot have its own parent. Additionally, both parent and child flags must belong to the same project. + +A child feature flag is evaluated only when both the child and its parent feature are **enabled in the same environment** and the parent dependency value is met. You can set the parent dependency value to one of the following: + +- Parent feature is enabled. +- Parent feature is disabled: Useful when the parent acts as a kill switch with inverted enabled/disabled logic. +- Parent feature is enabled with variants: Useful for A/B testing scenarios where you need specific variant dependencies. + +To add a dependency, you need the `update-feature-dependency` project permission. In the Admin UI, go to the feature flag you want to add a parent to and select **Add parent feature**. + +![Feature lifecycle](/img/add-parent-flag.png) + +Archiving a child feature flag also removes its dependencies on parent feature flags. A parent feature cannot be archived if it has any child dependencies; in such cases, remove the dependencies, or archive both parent and child together. + +Note that metrics are affected only by child feature flag evaluations. + +### Variant dependencies + +:::note Availability + +**Plan**: [Pro](https://www.getunleash.io/pricing) and [Enterprise](https://www.getunleash.io/pricing) | **Version**: `5.12+` + +::: + +Variant dependencies are satisfied if the parent feature variant is evaluated to the expected value. +The parent dependency variant is compared to the actual value of the parent in a given environment. + +## Set a naming pattern + +:::note Availability + +**Plan**: [Enterprise](https://www.getunleash.io/pricing) | **Version**: `5.7+` + +::: + +A consistent and unique feature flag naming pattern reduces risks and simplifies flag management by preventing the reuse of old names, which could accidentally re-enable outdated features. +Unique names also make it easier to track and search for flags across codebases, ensuring clarity on what each flag controls and its purpose. + +To define a new naming convention for a project, go to **Project settings > Enterprise settings**. For **Naming Pattern**, define a valid [JavaScript regular expression](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp). +Optionally, you can provide an example and a description to guide users when creating new flags. + +Once saved, all future feature flag names in the project, including those created via the API, must follow the defined pattern. Note that the full feature flag name must match the pattern; partial matches are not sufficient. + +For example, you could set a pattern like `^(red|blue|green)\.[a-z-]+\.[0-9]+$`. You could then provide an example of a valid feature flag name, such as "blue.fast-checkout.64" and a description like: "`..`" to clarify the structure. + +## Archive a feature flag + +You can archive a feature flag once you no longer need it. To do so, go to the feature flag's page and click **Archive feature flag**. + +Once archived, the flag is no longer available to client SDKs. + +![Archive a feature flag](/img/archive-feature-flag.png) + +### View archived flags + +To view an archived feature flag, open the project that contains the flag and select the **Archived flags** tab. + +### Revive a feature flag + +You can revive archived flags by navigating to the [feature flag archive](#view-archived-flags) and clicking **Revive feature flag**. Revived flags are in an inactive state by default. + +### Delete a feature flag + +You can delete archived flags by navigating to the [feature flag archive](#view-archived-flags) and clicking **Delete feature flag**. + +However, we recommend not deleting feature flags unless they are completely removed from your codebase. If you delete a flag and later create a new one with the same name, it might unintentionally reactivate old code that still references the original flag. -While variants are most often used for A/B testing and the like, you can also use variants to assign a constant payload to a flag. If you give a flag only a single variant and that variant has a payload, then all users variants will receive that payload. diff --git a/website/docs/reference/stickiness.md b/website/docs/reference/stickiness.md index d5edc6bfa4..4b2f091102 100644 --- a/website/docs/reference/stickiness.md +++ b/website/docs/reference/stickiness.md @@ -20,7 +20,7 @@ For instance: When using the [gradual rollout activation strategy](../reference/ :::note Availability -**Plan**: [Enterprise](https://www.getunleash.io/pricing) | **Version**: `4.0+` and [SDK compatibility](../reference/sdks/index.md#server-side-sdk-compatibility-table) . +**Plan**: [Enterprise](https://www.getunleash.io/pricing) | **Version**: `4.0+` and [SDK compatibility](../reference/sdks/index.md#server-side-sdk-compatibility-table). ::: diff --git a/website/docs/reference/strategy-variants.md b/website/docs/reference/strategy-variants.md index 41031c9a73..2ac817a981 100644 --- a/website/docs/reference/strategy-variants.md +++ b/website/docs/reference/strategy-variants.md @@ -131,3 +131,8 @@ To make use of strategy variants, you need to use a compatible client. Client SD If you would like to give feedback on this feature, experience issues or have questions, please feel free to open an issue on [GitHub](https://github.com/Unleash/unleash/). + + +## Environment level variants + +[Environment level variants](./feature-toggle-variants) are deprecated. Use strategy variants instead. \ No newline at end of file diff --git a/website/docs/reference/technical-debt.md b/website/docs/reference/technical-debt.md index 7b41b8145d..f6e205fdd2 100644 --- a/website/docs/reference/technical-debt.md +++ b/website/docs/reference/technical-debt.md @@ -8,7 +8,7 @@ At Unleash we care deeply about code quality. Technical debt creeps up over time When a flag is no longer useful, we say that it has become _stale_. A stale flag is a flag that has served its purpose and that you should remove from the code base. For a flag to become stale, you have to explicitly mark it as such. You can mark a flag as stale in the [technical debt dashboard](#the-technical-debt-dashboard). -Unleash also has a concept of _potentially_ stale flags. These are flags that have lived longer than what Unleash expects them to based on their [feature flag type](../reference/feature-toggle-types.md). However, Unleash can't know for sure whether a flag is actually stale or not, so it's up to you to make the decision on whether to mark it as stale or to keep it as an active flag. +Unleash also has a concept of _potentially_ stale flags. These are flags that have lived longer than what Unleash expects them to based on their [feature flag type](../reference/feature-toggles#feature-flag-types). However, Unleash can't know for sure whether a flag is actually stale or not, so it's up to you to make the decision on whether to mark it as stale or to keep it as an active flag. A flag being (potentially) stale, does not affect how it performs in your application; it's only there to make it easier for you to manage your flags. diff --git a/website/docs/topics/feature-flags/best-practices-using-feature-flags-at-scale.md b/website/docs/topics/feature-flags/best-practices-using-feature-flags-at-scale.md index dba96e1503..09f5e2ceea 100644 --- a/website/docs/topics/feature-flags/best-practices-using-feature-flags-at-scale.md +++ b/website/docs/topics/feature-flags/best-practices-using-feature-flags-at-scale.md @@ -291,7 +291,7 @@ A good rule of thumb is that if the data is static (you don’t expect it to cha Feature flag names need to be globally unique. [We wrote about this before](https://docs.getunleash.io/topics/feature-flags/unique-names), but it is such an important point that it bears repeating. Every feature flag within the same Feature Flag Control service must have a unique name across the cluster to prevent inconsistencies and errors. -In a perfect world, all references to feature flags in code would be cleaned up as soon as the feature flag is archived. But we don’t live in a perfect world. You will save yourself many hours of frustration and potential downtime if you use unique names to protect new features from being accidentally linked to outdated flags, which could inadvertently expose old features. [Unique names should ideally be enforced during flag creation](https://docs.getunleash.io/reference/feature-flag-naming-patterns). +In a perfect world, all references to feature flags in code would be cleaned up as soon as the feature flag is archived. But we don’t live in a perfect world. You will save yourself many hours of frustration and potential downtime if you use unique names to protect new features from being accidentally linked to outdated flags, which could inadvertently expose old features. [Unique names should ideally be enforced during flag creation](https://docs.getunleash.io/reference/feature-toggles#set-a-naming-pattern). ### 14. Avoid giant feature flag targeting lists. diff --git a/website/docs/understanding-unleash/the-anatomy-of-unleash.mdx b/website/docs/understanding-unleash/the-anatomy-of-unleash.mdx index c4b4a67ff5..ad739aa2b9 100644 --- a/website/docs/understanding-unleash/the-anatomy-of-unleash.mdx +++ b/website/docs/understanding-unleash/the-anatomy-of-unleash.mdx @@ -66,7 +66,7 @@ When connecting an SDK to Unleash, it's the **API key that decides which environ [**Feature flags**](../reference/feature-toggles.mdx) are at the heart of Unleash’s functionality. Feature flags belong to projects and live next to project environments. In and of itself, a feature flag doesn’t do anything. You must assign [**activation strategies**](../reference/activation-strategies.md) to it for it to start taking effect. -When creating a feature flag, you must assign a unique (across your Unleash instance) name, a [feature flag type](../reference/feature-toggle-types.md), a [project](../reference/projects.md) it belongs to, and an optional description. Everything except for the name can be changed later. +When creating a feature flag, you must assign a unique (across your Unleash instance) name, a [feature flag type](../reference/feature-toggles#feature-flag-types), a [project](../reference/projects.md) it belongs to, and an optional description. Everything except for the name can be changed later.