Move settings methods to app.settings and deprecate old versions #3714
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Started as a
5.x
PR, this is the deprecation version for the4.x
branch. See: #3218The only thing I am worried about this this is that the
app.settings
object has changed. It used to be a plain object, and is now an instance ofSettings
. I think some purists would call that a breaking change. The problem is that there is no way to provide the new functionality without changing that object.If we had a faster major release cadence, we could deprecate in
5.0
(breaking direct.settings
access) and remove in6.0
. But that might be YEARS, and speeding up majors is a different topic, one which I think we should do. So IMO I think we have two options:5.0
.I am perfectly happy with either, but if I had a choice it would be 1 because it preps people who are using it for 5.0 and the churn on this api shouldn't be much and is worth it.