<p>The two approaches whilst somewhat overlapping solve two different problems:</p>

<ul>
<li><p>Feature flags allow you to <strong>decouple the action of deployment from the action of release</strong>.  i.e. you can push a change to an API that adds functionality to support a new feature, then when your product owner wants to release it all they need to do is toggle the feature on.</p></li>
<li><p>API versioning enables you to make changes to your API without breaking compatibility with older clients.</p></li>
</ul>

<p>In both cases, you need to ensure that old feature flags and old API versions are eventually removed from the codebase or it will become very complicated very quickly.  </p>

<p>The deciding factor comes down to whether or not you have control over all of your clients if you can guarantee that you can make changes to both your clients and the API in such a way that they will remain compatible, or incompatible clients can be removed from your ecosystem very quickly you probably don't need API Versioning.</p>

CC BY-SA 4.0
2019-11-19T17:51:21.530Z
Thanks @richard-slater. In my case all APIs are internal to the same product dev teams and we have complete control and co-ordinate changes between different APIs and UI, so I am struggling to see what benefits API versioning will provide. IMHO, as per tenets of Trunk based development in order to keep feature branches short-lived, we could also use feature flags to hide features that have not been implemented completely. Correct me if I am wrong...
VKR
CC BY-SA 4.0
2019-11-20T08:44:33.933Z
Hiding partial implementations through feature flagging is perfectly acceptable, although it does suggest that perhaps you need to further decompose your features.
Richard Slater
CC BY-SA 4.0
2019-11-19T17:20:05.663Z
2019-11-19T17:20:05.663Z
Richard Slater
<ul>
<li><p><strong>Feature flags</strong> are preferred when toggle needs to be done for shorter duration (for internal teams this can be a good approach).</p>
</li>
<li><p><strong>API versionning</strong> is best suitable for long term different features needs to be provided (for external facing apps).</p>
</li>
</ul>

CC BY-SA 4.0
2023-11-07T16:10:05.150Z
2023-11-07T16:10:05.150Z
skakkar
<p>We are looking at moving to a trunk based development branching strategy rather than gitflow that we currently use. I understand that feature flags are crucial to trunk based development. However, is there still a place for versioning APIs if I am using feature flags to control exposure of new features across UI and APIs?</p>

<p>All of our APIs are are internal to our application and are not exposed directly to  a third party. Even in a case like changes in schema for response/requests - those could be treated as a new feature and handled via a feature flag to enable dark deployments etc. So, what would be a good case to still use API versioning if I have feature flags going?</p>

<p>Will appreciate any thoughts from your experience or any good articles you have come across related to this topic.</p>

<p>Thank you - VK</p>

<continuous-integration><cicd><versioning><feature-toggles><feature-flags>
feature flags vs versioning for APIs
VKR
# feature flags vs versioning for APIs

(Asked by: username_0 on 2019-11-18)

We are looking at moving to a trunk based development branching strategy rather than gitflow that we currently use. I understand that feature flags are crucial to trunk based development. However, is there still a place for versioning APIs if I am using feature flags to control exposure of new features across UI and APIs?

All of our APIs are are internal to our application and are not exposed directly to a third party. Even in a case like changes in schema for response/requests - those could be treated as a new feature and handled via a feature flag to enable dark deployments etc. So, what would be a good case to still use API versioning if I have feature flags going?

Will appreciate any thoughts from your experience or any good articles you have come across related to this topic.

Thank you - VK

**Tags:** continuous-integration, cicd, versioning, feature-toggles, feature-flags


---

## 2 answers

### Answer by username_1 on 2019-11-19. Score: 2

The two approaches whilst somewhat overlapping solve two different problems:

* Feature flags allow you to **decouple the action of deployment from the action of release**. i.e. you can push a change to an API that adds functionality to support a new feature, then when your product owner wants to release it all they need to do is toggle the feature on.
* API versioning enables you to make changes to your API without breaking compatibility with older clients.

In both cases, you need to ensure that old feature flags and old API versions are eventually removed from the codebase or it will become very complicated very quickly.

The deciding factor comes down to whether or not you have control over all of your clients if you can guarantee that you can make changes to both your clients and the API in such a way that they will remain compatible, or incompatible clients can be removed from your ecosystem very quickly you probably don't need API Versioning.

> **Comments:**
> **username_0**: Thanks @richard-slater. In my case all APIs are internal to the same product dev teams and we have complete control and co-ordinate changes between different APIs and UI, so I am struggling to see what benefits API versioning will provide. IMHO, as per tenets of Trunk based development in order to keep feature branches short-lived, we could also use feature flags to hide features that have not been implemented completely. Correct me if I am wrong...  
> **username_1**: Hiding partial implementations through feature flagging is perfectly acceptable, although it does suggest that perhaps you need to further decompose your features.  

---

### Answer by username_2 on 2023-11-07. Score: 0

* **Feature flags** are preferred when toggle needs to be done for shorter duration (for internal teams this can be a good approach).
* **API versionning** is best suitable for long term different features needs to be provided (for external facing apps).


---

