Repository navigation
Replies: 3 comments 4 replies
|
Does this proposal conflict with For example:
Actually we have Then we also have |
|
yeh. we are just not consistent right now. Actually i don't think it conflicts overall, but instead consolidates all values to be in a range from |
|
With regards to breaking changes we should have a standard approach to dealing with breaking changes in config. I don't think just breaking it from one release to the next is the way to go, and we'd need to some way of deprecating previous config, etc. |
|
Hmm.. First thing i think of is: We could introduce a "deprecated" flag in the PropertyMapper, and if deprecated it won't be shown in the cli help anymore (instead the new config would be) but could be used still from the CLI and other config sources. Docs would show a "deprecated" sign, perhaps on a different table. So we'd have a somewhat graceful deprecation period without too much manual stuff to do (one would still need to check the docs for occurences of "deprecated" config in examples, though. But perhaps this would also be solveable, but then we'd had to check the parameters from the examples, and imo the build should fail with a message "found deprecated variable in example in guide: {guide}"). wdyt? |
|
+1 To deprecated flag in PropertyMapper. I assume we'd also print a warning when a deprecated option is used? +1 To not including in CLI --help For docs I have wanted for a while a single place where we list deprecated features, as that is a bit scattered all over the place right now. Wonder if it would be best to have a single section in the upgrade guide perhaps that has a list of deprecated features, including the deprecated config options, then not have them listed at all in the new server guides? +1 To some unit tests for the guides to complain if invalid options are used, including deprecation options. |
|
Would it be an idea to attach this proposal to a design proposal around extensions, and how they are configured? |
|
yep, there's definitely overlap / touching points and this should be aligned with an extension proposal. |
Uh oh!
There was an error while loading. Please reload this page.
In Keycloak 17, we often use the following format for the configration keys:
<name-enabled>=<bool>This gets very long sometimes and imo it just feels doubled.
Two Examples:
transaction-xa-enabled=true/falsecould be shorter by using:
transaction-xa=true/falsehttp-enabled=true/falsecould be shorter using:
http=true/falseAs I know this breaks many things, I guess we should have done this before releasing kc 17. Well, we didn't, but imo we should, and if we won't do it now, we are really stuck forever with the longer and imo bad naming format, so I still want to suggest to change the format for enabled/disabled switches.
Decision 1:
Do we still want to change?
if yes:
Decision 1.1:
What should the new values look like? boolean
trueandfalseorenabledanddisabled, or both?if not
then lets close this discussion.
All reactions