From @dregad:

Sorry @vboctor but I think @schriftgestalt is right - in terms of consistency, we actually have more settings named $g_view_xxx_threshold than we have $g_xxx_view_threshold:

$ git grep ^\$.view.thresh -- config_defaults_inc.php
config_defaults_inc.php:1484:$g_view_summary_threshold = MANAGER;
config_defaults_inc.php:1601:$g_view_sponsorship_total_threshold = VIEWER;
config_defaults_inc.php:1608:$g_view_sponsorship_details_threshold = VIEWER;
config_defaults_inc.php:2102:$g_view_attachments_threshold = VIEWER;
config_defaults_inc.php:2539:$g_view_bug_threshold = VIEWER;
config_defaults_inc.php:2598:$g_view_handler_threshold = VIEWER;
config_defaults_inc.php:2605:$g_view_history_threshold = VIEWER;
config_defaults_inc.php:2655:$g_view_proj_doc_threshold = ANYBODY;
config_defaults_inc.php:2791:$g_roadmap_view_threshold = VIEWER;
config_defaults_inc.php:2803:$g_timeline_view_threshold = VIEWER;
config_defaults_inc.php:3020:$g_view_configuration_threshold = ADMINISTRATOR;
config_defaults_inc.php:3832:$g_tag_view_threshold = VIEWER;
config_defaults_inc.php:3896:$g_time_tracking_view_threshold = DEVELOPER;
config_defaults_inc.php:4014:$g_due_date_view_threshold = NOBODY;
(list edited to remove a few configs which match the regex but are actually not view thresholds)

That's 9x view_xxx vs 4x xxx_view (not counting the new timeline config). Based on that, I would rather have it like @schriftgestalt originally submitted.

Then we can discuss whether we should update $g_roadmap_view_threshold, $g_tag_view_threshold, $g_time_tracking_view_threshold and $g_due_date_view_threshold for consistency.

From @vboctor:

I don't think the count is the deciding factor here. It is what we want to consider as the old way of doing it vs. the new way of doing it.

I personally prefer the $g_feature_knob model since it enables nice natural grouping and auto-complete for all configs relating to a feature:

$g_roadmap_enabled
$g_roadmap_view_threshold
$g_roadmap_etc

rather than

$g_view_roadmap_threshold
$g_view_changelog_threshold
$g_etc_roadmap
$g_enabled_changelog
$g_enabled_roadmap

You get my point.

From @dregad:

OK fair enough, that makes sense - in that case let's do the update the other way around (I was just thinking about minimizing the number of obsoleted configs)

I think we should use the preferred model for the new configs. For existing configs, our deprecation model is designed for handle these configs within config_inc.php, but it doesn't handle very well the case where these old configs are set in the database (or maybe my recollection is wrong, I haven't checked). We may want at one point supporting the concept of "a" became "b" at retrieval time or we could consider schema change step(s). The existing model errors out on use of old config and possible recommend looking at a different config. That model doesn't distinguish new config being 100% compatible (but just name difference) vs. incompatible field (e.g. enabled flag vs. threshold).

our deprecation model is designed for handle these configs within config_inc.php, but
it doesn't handle very well the case where these old configs are set in the database

config_obsolete() actually covers both the case of config_inc.php definitions, as well as database configuration. That's something I fixed several years ago (see 0013435).

The limitation is that we only detect obsolete configs in admin checks (config_obsolete() via inclusion of obsolete.php in check_config_inc.php).

The existing model errors out on use of old config

In theory, the old config should not be referenced anywhere in the code base after it is obsoleted, the only potential issue might be with plugins. In that case, I think erroring out is the right thing to do.

The more important issue would be for admins who don't run the checks after upgrade, and might therefore see their system silently fall back to a default value. For example:

BEFORE: restricting view of issue history to developers

config_defaults_inc.php: $g_view_history_threshold = VIEWER;

custom local config:     $g_view_history_threshold = DEVELOPER;

AFTER: the system displays history for all users, no errors...

config_defaults_inc.php: $g_history_view_threshold = VIEWER;

obsolete.php:            config_obsolete( 'view_history_threshold', 'history_view_threshold' );

custom local config:     $g_view_history_threshold = DEVELOPER;

Admin checks do detect this:

The configuration option view_history_threshold is now obsolete

it is currently defined in config_inc.php, as well as in the database configuration for:
All Users: All Projects

Short of caching the list of obsolete configs in config_api.php and checking for obsolete ones whenever we call config_get(), I don't see how we could avoid that.

IMO it would be unnecessary overhead, and I'm not convinced trying to build a mechanism to automate is actually worth the effort. We already provide a hint about which replacement to use (the 2nd param to config_obsolete()); to go the extra mile, we would have to set some kind of additional flag to indicate 1:1 replacements (renames).