Handbook: Product groups: Changing configuration

[Sampfluger88]

Propose somewhere in the handbook for this tip about designing changes to Fleet's config surface :

• ("Why this way?" is probably the right thing)

  Tip: To pass on to the rest of the team at eg. estimation

• Whenever we are dealing with deprecated/renamed config, this is the pattern I learned (the hard way) to use in dealing with these kinds of changes: At server start:
• we validate that both the old deprecated thing and the new thing aren't both set Note: if so clear, error message telling user how to fix. Then the config is fixed automatically (ideally this also logs a ONE-TIME deprecation warning telling the user to change to the new config)
• From then on, Fleet uses the proper config
• docs are changed to only reflect the non-deprecation

[mikermcneil]

Goal: In pursuit of consistency and OSS project maturity in the Fleet docs: This’ll give users and contributors clarity on how breaking changes to config work.

@zwass Would love to have it reflect whatever the philosophy we’ve been using so far has been, if there is a firm one yet, and if not, we’ll start with the aspiration and follow up to jot down where things are actually at.

[fleet-release]

Config change unfolds, Error messages guide the way, Fleet sails smoother seas.