---
title: "What is GitLab's feature deprecation strategy?"
author: Sid Sijbrandij
author_gitlab: sytses
author_twitter: sytses
categories: unfiltered
image_title: "/images/blogimages/gitlab-values-cover.png"
description: "We release a lot of new features every month! Curious how we're thinking about deprecation?"
---

{::options parse_block_html="true" /}

<i class="fab fa-gitlab" style="color:rgb(107,79,187); font-size:.85em" aria-hidden="true"></i>&nbsp;&nbsp;
This blog post is [Unfiltered](/handbook/marketing/blog/unfiltered/#legal-disclaimer)
&nbsp;&nbsp;<i class="fab fa-gitlab" style="color:rgb(107,79,187); font-size:.85em" aria-hidden="true"></i>
{: .alert .alert-webcast}

What is our deprecation strategy for features? 
We add a ton of features to our product every single month. 
It can be a not-great user experience or development experience, if you don't deprecate any of them. 
When we have features that are widespread in the codebase but don't have a lot of usage, it holds us back. 

We deprecate features for the same reasons a lot of other companies do, including not generating revenue and not being utilized.
I think what's really important is technical debt interest rate. 
For a feature that exists, it's important to consider how it prevents future features from being added and how it may be infecting existing or potential features with code that could be a higher quality. 

Our mission is Everyone Can Contribute. 
Every time you add a new feature, it needs to be a solid base for people to build on. 

Here are some more of my thoughts on how we deprecate features:

<figure class="video_container">
  <iframe src="https://www.youtube.com/embed/AH0B4k0Ibz0" frameborder="0" allowfullscreen="true"> </iframe>
</figure>