Partition old configuration into deprecation/legacy #906
Conversation
|
🎊 PR Preview has been successfully built and deployed to https://localstack-docs-preview-pr-906.surge.sh 🎊 |
There was a problem hiding this comment.
Great initiative 🚀 . I like the separation and metadata about when it was removed.
Improved configuration handling and communication is something we should tackle 📈
Two discussion points:
- How long should we keep the legacy variables at all? one extra major release, forever?
- How do we go about adding the deprecation flag inline (i.e., within the subsection) vs. globally?
For Lambda, we still have the migration guide but I'm also fine with re-adding them for configuration discoverability at one page, if labelled clearly.
|
The most urgent thing is probably to synchronize the list with |
I wouldn't call it urgent, but yeah definitely want to have this synced until next week! |
Yes that was our thinking. At least forever mentioning that they once existed.
It's probably not needed anymore to have it inline, I'll remove this in a follow-up when adding more items |
Introduces a new partitioning of older configuration values to unify how we communicate their deprecation status.
Deprecated... Still supported in latest version but should not be used anymore. Will be removed in one of the next major releases.Legacy... Has been removed in a previous major release. Does NOT affect the latest version anymore.Follow-up
We should probably also cover variables we've just removed from the list in the past.
This isn't super urgent but we should make sure we sync the deprecation status here with the ones we're tracking in localstack.