Featurevisor v3.0 is here! - Featurevisor← See all postsBy Fahad Heylaal on July 12, 2026

Featurevisor v3.0 is here, focused on making projects easier to organize and scale , datafiles easier to shape , and SDKs easier to use consistently across multiple different languages , with first class support for AI agents .<br>This is a breaking release, but the generated datafile schema remains version 2.<br>That means you can upgrade your Featurevisor project first, publish v3-generated datafiles, and then upgrade application SDKs one by one at your own pace allowing you to coordinate the release with your application teams very conveniently .<br>What's new?#<br>The biggest changes in v3 are:<br>Targets replace scopes and automatic tag-based datafile generation.<br>Catalog is a new server for browsing your definitions.<br>Sets let one repository contain multiple independent project trees.<br>Promotions copy definitions between sets, with optional promotion flows.<br>Feature tags are now optional.<br>Projects have no default environments unless you define them.<br>Namespaced keys use . as the default separator.<br>JavaScript SDK now uses createFeaturevisor() as the main API.<br>SDK modules replace hooks.<br>SDK diagnostics replace the old logger API.<br>setDatafile() merges by default, enabling loading datafiles incrementally.<br>Go, Swift, Java, Ruby, Python, and PHP SDKs have been ported to v3 behavior.<br>Catalog in AI Agents#<br>With skills, you can start Featurevisor's new catalog server within your AI agent's browser directly for ease of browsing your definitions, while still prompting for making any changes.

When I started Featurevisor, I built it with the idea of developers writing the definitions by hand declaratively. Now I feel we live in a different world where AI agents are more capable of generating the definitions for us better.<br>Being strictly declarative has been very advantageous for Featurevisor leveraging agentic workflows. Combine prompting with browseable catalog in your favourite AI agent, and you have a powerful combination for managing everything.<br>Targets for datafiles#<br>Scopes were previously introduced to make smaller datafiles from partially known contexts. In v3, that responsibility belongs to Targets.

Targets live as files in the targets directory:<br>targets/web.yml

description: Web datafile

# pick all features tagged with 'web'<br>tag: web

# apply partially known context upfront<br># to reduce conditions/segments/rules in generated datafile<br>context:<br>platform: web

You can also select features directly:<br>targets/checkout.yml

description: Checkout features

includeFeatures:<br>- checkout*<br>- shared.navigation

excludeFeatures:<br>- checkout.internal*

Every datafile is now produced from a target. The smallest possible target is simply:<br>targets/all.yml

description: All features

Unless anything else is specified, the target will include all features in the project.<br>The generated datafiles follow the convention of datafiles//featurevisor-.json.<br>Sets and promotions#<br>With Sets, which is optional to adopt, a project can be split into independent trees:<br>sets/<br>├── dev/<br>├── staging/<br>└── production/

Each set owns its own attributes, segments, features, targets, and tests. You can then use Promotions to move definitions forward:<br>$ npx featurevisor promote --from=dev --to=staging --apply

This works well for teams that want release lanes, ownership boundaries, or distinct surfaces while keeping everything Git-based.<br>The same sets-based approach also be used for completely different areas of your business, such as different products, teams, or geographies, that need to be managed independently.<br>SDKs#<br>The JavaScript SDK has a smaller and clearer public API:<br>import {<br>createFeaturevisor,<br>type Featurevisor,<br>type FeaturevisorOptions,<br>type FeaturevisorModule,<br>} from '@featurevisor/sdk'

Modules replace hooks:<br>const trackingModule: FeaturevisorModule = {<br>name: 'tracking',<br>after(evaluation) {<br>// send exposure or diagnostic data to your own system<br>return evaluation<br>},

const f = createFeaturevisor({<br>datafile,<br>modules: [trackingModule],<br>})

Diagnostics are now the standard way to observe SDK behavior:<br>const f = createFeaturevisor({<br>logLevel: 'info',<br>onDiagnostic(diagnostic) {<br>// send to your observability system<br>},<br>})

Nothing changes for the evaluation methods.<br>The Go, Swift, Java, Ruby, Python, and PHP SDKs have also been aligned with the same v3 behavior where practical for each language.<br>Datafile schema#<br>Featurevisor v3 still generates schema version 2 datafiles:<br>"schemaVersion": "2"

The old v1 datafile generation path and --schema-version selection are gone from active usage.<br>If you still have a consumer that requires v1 datafiles, keep using an older Featurevisor v2 CLI for that consumer while you migrate it.<br>Migration guide#<br>The full migration guide is available here:<br>Migrating from v2 to v3<br>The recommended path is:<br>Upgrade your Featurevisor project and generate v3 datafiles.<br>Publish the datafiles.<br>Upgrade application SDKs one at a time.<br>Because the datafile...