-
Notifications
You must be signed in to change notification settings - Fork 652
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor configuration #2300
Refactor configuration #2300
Conversation
…fault configs with custom instead of filling custom configuration with default values)
This is great! Everything looks good so far. Just mark this as ready whenever you are. The proposed .NET Core-compatible configuration syntax is 💯. |
The future improvements in this area seems quite complicated and I'd prefer to keep the current changes in a separate PR. So I'm marking this PR as ready for review. If the changes look good to merge at this point, I think it would be better to do that. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Besides DefaultConfigProvider.CreateDefaultConfig
being static
I think this is fantastic work! 👏
I'm sorry, but I don't have enough time right now to do exactly what you've asked (immutable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fabulous work! 👏
Thank you so much for this, @Inok! 🙏 Whenever you find time, I would love to accept a PR with immutable |
🎉 This issue has been resolved in version 5.3.6 🎉 Your GitReleaseManager bot 📦🚀 |
It's a first step towards configuration refactoring.
All tests pass and I did my best to not introduce any breaking changes. However, the changes are quite huge, so it's a draft at this moment and I personally think it should not be released as part of 5.3.x. My intention in this PR is to show what I've done, to ask whether the changes are appropriate or not, and to discuss further steps.
@asbjornu, could you please review the changes? What do you think about them and about the next step I suggested below?
Description
I reversed the order of configuration merging. The previous approach was "read custom configuration and add default values to what's empty". The new approach is more natural: "create default configuration, override by configuration from source 1, override by...".
Previously, several config-level settings has been written to the branch config right on merging (IncrementStrategy and VersioningMode). The new approach does that on the very last step: on the configuration finalization. Now the configuration should be built like this:
Next step
I guess, the next step is to do something like that:
So it will be similar to .NET Core's configuration.