Add feature flag removal section from Confluence #680
Conversation
trmartin4
changed the title
Deploying contributing-docs with
|
| Latest commit: |
cd9b49f
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://6872c46f.contributing-docs.pages.dev |
| Branch Preview URL: | https://add-flag-removal-section.contributing-docs.pages.dev |
|
Great job! No new security vulnerabilities introduced in this pull request |
|
|
||
| **Step 2** can take place either: | ||
|
|
||
| - Three major releases after the feature flag was removed from the clients in **Step 1**, if the |
There was a problem hiding this comment.
There was a problem hiding this comment.
Don't we need that in order to meet our backward compatibility guarantees? If I release a feature in version N, and then remove the feature flag from clients and server in version N+1, when server version N+1 is deployed, the version N client will no longer receive the feature flag value in the /api/config response and default to false, disabling the feature that we just rolled out.
Is there some protection in place that I'm not aware of that would prevent that?
There was a problem hiding this comment.
There's a subtlety to feature flag usage, and I think literally having "feature" in the term can be confusing, but the intention is for them to live and die fast for the purposes of deployment and release resiliency first and foremost; gating functionality is indeed a benefit but it wasn't quite the point when I introduced them.
We do of course have a support policy, but that's for client-server interaction and my stance is that feature flags are not actually related to it. If you're going to use and benefit from something in N, then when N+1 comes you must also stay up to date if you expect to continue using whatever was flagged. Our support policy is about maintaining an operable state and not about getting anything and everything available.
Put simply, I feel the best way to operate is to have a client release that removes the use of the flag, is released and therefore available to users, and then the server can cease emitting that flag.
There was a problem hiding this comment.
I'm not opposed to this change, but I can just about guarantee that most devs have the same understanding as @trmartin4, so please make sure this is widely shared in Slack.
It also means (as I understand it) that we may not necessarily remove old code with the feature flag like we do today. e.g. a feature flag would be removed the N+1 release, but you may have to keep an old endpoint until N+3 if it's a breaking change. Whereas today we would keep both until N+3 and remove them together. That's not a problem, maybe that's even a better way to think about it, but something we'll have to think about differently.
4 participants
📔 Objective
I had some feedback that the bifurcation of feature flag lifecycle documentation between Contributing Docs and Confluence caused some confusion for those who were trying to learn and participate in our process. Namely, we had the process for creating and using flags here, but then we had documentation in Confluence for how to unwind a flag here.
This PR moves the documentation from Confluence into Contributing docs.
The remainder of that Confluence document details how to do specific targeting rules in LaunchDarkly that are not a core part of the feature flag SDLC, so once this PR is merged I will rename the internal docs to reflect that smaller scope.
⏰ Reminders before review
team
🦮 Reviewer guidelines
:+1:) or similar for great changes:memo:) or ℹ️ (:information_source:) for notes or general info:question:) for questions:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmedissue and could potentially benefit from discussion
:art:) for suggestions / improvements:x:) or:warning:) for more significant problems or concerns needing attention:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt:pick:) for minor or nitpick changes