🔥 Unleash v6

[ivarconr]

Decided:

• Upgrade to Node v20 @chriswk
  - Node20 #7095
• Dropping support for postgres v10, v11, and v12.
  • Make unleash fail to start with a error message if you try to connect to an old postgres version. This to future proof our ability to take advantage of v13+ capabilites. https://www.postgresql.org/support/versioning/ @chriswk
  • feat: error log on unsupported pg #7139
• Remove the passport libs from the official Open Source Docker distribution. (We have a community image which adds these dependencies). This is huge, because it allow us to drop the "docker" folder with added complexity to avoid those dependencies leaking in to the enterprise version. @chriswk
  • chore: removed passport from docker package.json file #7159
• Remove /edge/metrics endpoint @chriswk
  • task: Removed edge bulk metrics endpoint #7161
• Deprecate custom strategies (Notice in the UI, docs and the API specification. We recommend constraints instead). Also need to update the Open API spec to state the endpoint to create new ones deprecated. @sighphyre
• Deprecate "feature variants" in favor of "strategy variants". The goal is to "hide" it for all new feature flags being created. @kwasniew
• Remove legacy Google SSO provider. Use SAML 2.0 or OpenID Connect instead. @ivarconr
• Remove legacy "/api/feature" endpoint. Has been deprecated since Unleash v4.4. @daveleek
• Unleash Enterprise will make "License Key" mandatory. @ivarconr
• New global UI navigation (sidebar) @kwasniew
• Rename "feature toggle" to "feature flag" in the UI (will not change API schema and definition or SDKs to keep breaking changes to a minimum) @sjaanus
• Error types to be standardized on the message property (removing the description property) @thomasheartman
• Some deprecated properties in the OpenAPI spec will be removed @sighphyre
• Remove deprecated old import (state service). Also need to update docs for this. @daveleek
  • PS! We will drop support for file based import at statup (Import from file will be gone - [Deprecated] Import & Export #6306)
  • WE have plans to extend the current import capability to support this in the future (Feat: Extend "current" import/export capability to support file as a startup argument.  #7128)

Todo:

• Make sure our documentation reflects v6 requirements and capabilities.

Dropped (did not make it for the v6 plans)

• Migrate to ESM (uncertainty around jest support)
• Drop the id column in the permissions table (this is an internal db change).

Background

A major version is an opportunity to remove deprecated features and add new features to our deprecation list.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[gastonfournier]

unleash/src/lib/middleware/rbac-middleware.ts

Lines 73 to 92 in 9683dda

	// Temporary workaround to figure out projectId for feature toggle updates.
	// will be removed in Unleash v5.0
	if (
	!projectId &&
	permissionsArray.some((permission) =>
	[DELETE_FEATURE, UPDATE_FEATURE].includes(permission),
	)
	) {
	const { featureName } = params;
	projectId = await featureToggleStore.getProjectId(featureName);
	} else if (
	projectId === undefined &&
	permissionsArray.some(
	(permission) =>
	permission === CREATE_FEATURE ||
	permission.endsWith('FEATURE_STRATEGY'),
	)
	) {
	projectId = 'default';
	}

something to clean up

[chriswk]

Removing /edge/metrics endpoint

[sebastian-bury]

docs on upgrading from v5 to v6, changes needed, breaking things, etc.

[gastonfournier]

Should we consider consolidating all migration files into a single file? We have 276 migrations. We could do a fresh DB dump after all migrations to start fresh

[chriswk]

Should we consider consolidating all migration files into a single file? We have 276 migrations. We could do a fresh DB dump after all migrations to start fresh

What would be the gain? (Assume positive intentions, I'm curious, I'm not trying to be negative here)
My gut reaction is that this will complicate upgrades, and having the full DDL in one file will make that file unreadable.

[sighphyre]

What would be the gain? (Assume positive intentions, I'm curious, I'm not trying to be negative here) My gut reaction is that this will complicate upgrades, and having the full DDL in one file will make that file unreadable.

If I'm reading the original comment correctly, we'd squash all the migrations into a single SQL script which would give us the opportunity to avoid some of those dangerous migrations that need to be done in phases

I do agree though, this sounds like it'd cause more pain than happiness

[gastonfournier]

What would be the gain?

Asking the right questions! I was looking for performance gains. Gathering some data...

In my local machine.

• Running all migrations in a fresh db: 3555ms
• Running a single migration with a fresh dump: 1399ms

This also impacts on test execution speed. I ran yarn test resulting in:

Test Suites: 2 failed, 301 passed, 303 total
Tests:       2 failed, 2 skipped, 2786 passed, 2790 total
Snapshots:   103 passed, 103 total
Time:        199.772 s, estimated 203 s

And I logged up migration times:

• We execute 125 up migrations during our OSS tests (sometimes more than once per suite)
• Average time spent in test suites running up migrations: 4159.9 ms (note only 125 run up migrations and we have
• Total sum: 519987 ms (519 seconds while all tests run under 200 seconds can only be explained by concurrency)
• Maximum: 16776 ms

The issue is that the dump is not that great for migrations and without taking into account the failures I also didn't see a performance boost:

Test Suites: 34 failed, 269 passed, 303 total
Tests:       126 failed, 2 skipped, 2662 passed, 2790 total
Snapshots:   101 passed, 101 total
Time:        190.593 s, estimated 199 s

[damianh]

Support for in-memory mode would be great. Our use case would be to run the container in short lived isolated scenarios (e.g. integration testing, running apps locally, CI) and not having to also run Postgres as part of this would make the experience "lighter".

[ivarconr]

Dropping support for postgres v10, v11, v12 and v13.

@chriswk I think we need to support at least v13 for another year. We have a few larger enterprises still stuck on that version.

[ivarconr]

Support for in-memory mode would be great. Our use case would be to run the container in short lived isolated scenarios (e.g. integration testing, running apps locally, CI) and not having to also run Postgres as part of this would make the experience "lighter".

You can run https://github.com/Unleash/unleash-edge in offline mode to support that use case.

[alvinometric]

I would love to see ESM support 🥳

[sighphyre]

Some private legacy deprecated methods and properties that are no longer in use will be removed, pending assessment. This is purely internal to the source code

Has been removed. We've pretty good at trimming out unused stuff that's easy to remove