{"slug": "featurevisor-v3-open-source-feature-flags-management-with-git", "title": "Featurevisor v3 – open-source feature flags management with Git", "summary": "Featurevisor released version 3.0 of its open-source feature flag management tool, introducing targets, catalog, sets, and promotions to improve organization and scalability. The update adds first-class support for AI agents and allows incremental SDK upgrades with backward-compatible datafiles.", "body_md": "# Featurevisor v3.0 is here!\n\n[Fahad Heylaal](https://twitter.com/fahad19)on\n\nFeaturevisor 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**.\n\nThis is a breaking release, but the generated datafile schema remains version `2`\n\n.\n\nThat 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**.\n\n## What's new?[#](#whats-new)\n\nThe biggest changes in v3 are:\n\n[Targets](/docs/targets/)replace scopes and automatic tag-based[datafile](/docs/building-datafiles/)generation.[Catalog](/docs/catalog/)is a new server for browsing your definitions.[Sets](/docs/sets/)let one repository contain multiple independent project trees.[Promotions](/docs/promotions/)copy definitions between sets, with optional promotion flows.[Feature](/docs/features/#tags)`tags`\n\nare now optional.[Projects](/docs/projects/)have no default[environments](/docs/environments/)unless you define them.[Namespaced](/docs/namespaces/)keys use`.`\n\nas the default separator.- JavaScript\n[SDK](/docs/sdks/javascript/)now uses`createFeaturevisor()`\n\nas the main API. - SDK\n[modules](/docs/sdks/javascript/#modules)replace hooks. - SDK\n[diagnostics](/docs/sdks/javascript/#diagnostics)replace the old logger API. `setDatafile()`\n\nmerges by default, enabling[loading datafiles incrementally](/docs/use-cases/on-demand-datafiles/).[Go](/docs/sdks/go/),[Swift](/docs/sdks/swift/),[Java](/docs/sdks/java/),[Ruby](/docs/sdks/ruby/),[Python](/docs/sdks/python/), and[PHP](/docs/sdks/php/)SDKs have been ported to v3 behavior.\n\n## Catalog in AI Agents[#](#catalog-in-ai-agents)\n\nWith [skills](/docs/skills/), you can start Featurevisor's new [catalog](/docs/catalog/) server within your AI agent's browser directly for ease of browsing your definitions, while still prompting for making any changes.\n\nWhen 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.\n\nBeing 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.\n\n## Targets for datafiles[#](#targets-for-datafiles)\n\nScopes were previously introduced to make smaller datafiles from partially known contexts. In v3, that responsibility belongs to [Targets](/docs/targets/).\n\nTargets live as files in the `targets`\n\ndirectory:\n\n```\ndescription: Web datafile# pick all features tagged with 'web'tag: web# apply partially known context upfront# to reduce conditions/segments/rules in generated datafilecontext:  platform: web\n```\n\nYou can also select features directly:\n\n```\ndescription: Checkout featuresincludeFeatures:  - checkout*  - shared.navigationexcludeFeatures:  - checkout.internal*\n```\n\nEvery datafile is now produced from a target. The smallest possible target is simply:\n\n```\ndescription: All features\n```\n\nUnless anything else is specified, the target will include all features in the project.\n\nThe generated datafiles follow the convention of `datafiles/<environment>/featurevisor-<target>.json`\n\n.\n\n## Sets and promotions[#](#sets-and-promotions)\n\nWith [Sets](/docs/sets/), which is **optional** to adopt, a project can be split into independent trees:\n\n```\nsets/├── dev/├── staging/└── production/\n```\n\nEach set owns its own attributes, segments, features, targets, and tests. You can then use [Promotions](/docs/promotions/) to move definitions forward:\n\n``` bash\n$ npx featurevisor promote --from=dev --to=staging --apply\n```\n\nThis works well for teams that want release lanes, ownership boundaries, or distinct surfaces while keeping everything Git-based.\n\nThe 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.\n\n## SDKs[#](#sdks)\n\nThe JavaScript SDK has a smaller and clearer public API:\n\n``` js\nimport {  createFeaturevisor,  type Featurevisor,  type FeaturevisorOptions,  type FeaturevisorModule,} from '@featurevisor/sdk'\n```\n\nModules replace hooks:\n\n``` js\nconst trackingModule: FeaturevisorModule = {  name: 'tracking',  after(evaluation) {    // send exposure or diagnostic data to your own system    return evaluation  },}const f = createFeaturevisor({  datafile,  modules: [trackingModule],})\n```\n\nDiagnostics are now the standard way to observe SDK behavior:\n\n``` js\nconst f = createFeaturevisor({  logLevel: 'info',  onDiagnostic(diagnostic) {    // send to your observability system  },})\n```\n\nNothing changes for the evaluation methods.\n\nThe [Go](/docs/sdks/go/), [Swift](/docs/sdks/swift/), [Java](/docs/sdks/java/), [Ruby](/docs/sdks/ruby/), [Python](/docs/sdks/python/), and [PHP](/docs/sdks/php/) SDKs have also been aligned with the same v3 behavior where practical for each language.\n\n## Datafile schema[#](#datafile-schema)\n\nFeaturevisor v3 still generates schema version `2`\n\ndatafiles:\n\n```\n{  \"schemaVersion\": \"2\"}\n```\n\nThe old v1 datafile generation path and `--schema-version`\n\nselection are gone from active usage.\n\nIf you still have a consumer that requires v1 datafiles, keep using an older Featurevisor v2 CLI for that consumer while you migrate it.\n\n## Migration guide[#](#migration-guide)\n\nThe full migration guide is available here:\n\nThe recommended path is:\n\n- Upgrade your Featurevisor project and generate v3 datafiles.\n- Publish the datafiles.\n- Upgrade application SDKs one at a time.\n\nBecause the datafile schema remains version `2`\n\n, this can be done incrementally for applications already using v2-compatible SDKs.\n\n## Where we stand today[#](#where-we-stand-today)\n\nFeaturevisor has come a long way since its [inception](/blog/introducing-featurevisor/) in 2023, going stable with [v1](/blog/v1-release/) in the same year later.\n\n[SDK](/docs/sdks/) coverage has improved significantly since [v2](/blog/v2-release/) release last year, along with [skills](/docs/skills/) for AI agents too for more automation. Now even more powerful with the new [catalog](/docs/catalog/).\n\nv3 is all about making things more performant and scalable, especially for larger projects. I mean, **really large projects** with thousands of features, segments, rules, and what not. With the new improvements, I do not foresee scaling concerns being a blocker for adopting Featurevisor anymore.\n\nBased on the numbers from npm, the usage of Featurevisor has been growing steadily. And word of mouth will play a key role in the future. I am hoping the v3 release will help it grow even faster.\n\n## Going forward[#](#going-forward)\n\nI have been quietly expanding the visor family with [Messagevisor](https://messagevisor.com) (for i18n and l10n needs) and [Eventvisor](https://eventvisor.org) (for analytics schema governance), and I will be spending some time there to make them stable and production ready.\n\nThere will be synergy between the tools, like how Messagevisor already has a [Featurevisor module](https://messagevisor.com/docs/modules/featurevisor/). More to come on that front.\n\nGoal is still to keep them as separate projects, while making it easier to use them together. Once you get used to using one, it will feel natural to use the others too.\n\nAnd as more visors are adopted together, the faster you can leverage agentic workflows for the areas they cover. More recipes will arrive soon how to maximize the benefits of that.\n\n## Support[#](#support)\n\nStar on [GitHub](https://github.com/featurevisor/featurevisor), and follow me on [Twitter](https://x.com/fahad19) / [LinkedIn](https://www.linkedin.com/in/fahad19/) to get updates on the future of Featurevisor and the visor family.", "url": "https://wpnews.pro/news/featurevisor-v3-open-source-feature-flags-management-with-git", "canonical_source": "https://featurevisor.com/blog/v3-release/", "published_at": "2026-07-15 16:15:04+00:00", "updated_at": "2026-07-15 16:28:28.352732+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents"], "entities": ["Featurevisor", "Fahad Heylaal"], "alternates": {"html": "https://wpnews.pro/news/featurevisor-v3-open-source-feature-flags-management-with-git", "markdown": "https://wpnews.pro/news/featurevisor-v3-open-source-feature-flags-management-with-git.md", "text": "https://wpnews.pro/news/featurevisor-v3-open-source-feature-flags-management-with-git.txt", "jsonld": "https://wpnews.pro/news/featurevisor-v3-open-source-feature-flags-management-with-git.jsonld"}}