Deprecate old feature flags #9779
Comments
|
I jumped into production's Django shell and create a summary of each feature flag. I will start creating PRs with the ones that I think we can remove without any kind of notification/plan. Feel free to comment here if you have different opinions or what to do on each case.
|
|
Feature flags with 0 projects using them and
|
This is for projects that don't want to use our server side search.
This offers fuzzy search by default for projects, this is useful to get partial matches, instead of having to match an exact word, it does slow down search a bit, so it's under a feature flag.
This is useful when releasing a breaking change, or if we want to test something, and we are not sure if it will work for all projects |
I understand this feature flag will be able to be removed once we have addons in place as well, since we won't be injecting/integrating the Sphinx search input with our own search 👍🏼 |
|
Some patterns we've discovered:
|
|
My next step here is to update the table from my previous comment crossing-out the ones we removed, and updating the comments as needed. After that, we can discuss how we want to remove the ones that require a deprecation path and their priorities. Also, I want to update our meta discussion https://github.com/readthedocs/meta/discussions/68 with the learning from the current deprecation it's going on and define/set a generic plan for small and big impact deprecation. |
There are some leftovers here. CDN is enabled by default to all projects. Related #9779
|
This is the updated version of the table from #9779 (comment) without the ones that were removed already.
I will be taking one at a time and writing down each of the plans on Slack looking for approvals and I will implement the plan after that. |
Example using `build.jobs.pre_create_environment` to update Conda. We will link this example in the email we will be sending to users when deprecating/removing `UPDATE_CONDA_STARTUP` feature flag. See #9779
Example using `build.jobs.pre_create_environment` to update Conda. We will link this example in the email we will be sending to users when deprecating/removing `UPDATE_CONDA_STARTUP` feature flag. See #9779
|
There is some work going on here: storing some logs in NR to be able to contact these users and also waiting for the exact date to be able to remove some of the features for what users were already contacted. I'm putting this issue in a future sprint so I can come back to it and do the final work. |
We want to keep deprecating old feature flags we don't want to support forever. In particular, those that keep our users using pretty old versions of doctools and freeze them in a status that's hard to maintain. This PR removes the `DEFATUL_TO_MKDOCS_0_17_3` feature flag and always install the latest `mkdocs` version. Note this feature flag has `default_true=True` for those projects created _before 2019-04-03_. I did a small DB query and found: ```python >>> Project.objects.filter(pub_date__lt=timezone.datetime(2019, 4, 3), documentation_type='mkdocs').count() 7529 ``` However, note we don't know if these projects are pinning a version of MkDocs, so we don't exactly know how many of those are using this feature. However, it gives us a maximum number at least. On the other hand, taking a look at Metabase, using the build data from the past 6 months I found that we only have 293 projects: https://ethicalads.metabaseapp.com/question/218-projects-using-mkdocs-group-by-version Related #9779
|
This is the updated version of the table from #9779 (comment) without the ones that were removed already or are in the process.
I think there are no more feature flags we want to remove right now. I think we've done a really good work here by deprecating them, sending emails and moving forwards. The application is a lot more cleaner now and will allow us to move forward with more features. I'm moving this issue to Q4 for now so we can continue with the clean up of those feature flags that are not high priority. |
We need to contact each project and ask them to change the CNAME record to the new hashed one. I remember we contacted several of them in the past, so there are probably just a few using the old CNAME, we can also check which projects have the feature flag set. |
|
@stsewd Do we have an issue for this already? If not, we should create one to track that particular work that involves extra steps. I'm closing this generic issue since we are not going to remove more feature flags for now. |
We want to keep deprecating old feature flags we don't want to support forever. In particular, those that keep our users using pretty old versions of doctools and freeze them in a status that's hard to maintain. This PR removes the `DEFATUL_TO_MKDOCS_0_17_3` feature flag and always install the latest `mkdocs` version. Note this feature flag has `default_true=True` for those projects created _before 2019-04-03_. I did a small DB query and found: ```python >>> Project.objects.filter(pub_date__lt=timezone.datetime(2019, 4, 3), documentation_type='mkdocs').count() 7529 ``` However, note we don't know if these projects are pinning a version of MkDocs, so we don't exactly know how many of those are using this feature. However, it gives us a maximum number at least. On the other hand, taking a look at Metabase, using the build data from the past 6 months I found that we only have 293 projects: https://ethicalads.metabaseapp.com/question/218-projects-using-mkdocs-group-by-version Related #9779
With #9290 we removed some of the advertised feature flags we had added for users. There are still a few old feature flags kicking around that we might want to review more, and should remove what we think makes sense 1. While it would be ideal to remove all old feature flags, the ones most ripe for removal are:
The remaining feature flags we currently have are here:
https://github.com/readthedocs/readthedocs.org/blob/6e42d46/readthedocs/projects/models.py#L1798-L1844
For new beta features and new feature flags, the pattern we're moving back to is:
So, with that in mind, any old feature flag that seems major enough should be deprecated and should become a user-controllable configuration option.
I opened up #9698 to discuss configuration and opt-in for temporary/beta features. I think this solves the middle ground, where we want to develop and test a feature, but we need to communicate that the feature is beta quality still.
Footnotes
I would skip feature flags that are not heavily used and any feature that would be a sideways move. The goal is to give more control to users and keep user requests out of our support inbox. Going forward, I think a steady pattern for feature flags helps us the most. ↩
The text was updated successfully, but these errors were encountered: