You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given the subtle changes in additional config parameters as each version is released, it may be extremely useful to define the version at which each parameter was introduced.
This definitely seems like a good idea. There are two thing that will make it a bit tricky:
Sometimes the option is not new but just one of the values, e.g. repo-type=gcs.
It's not clear how we would handle deprecated options. For instance, pg1-path is only valid since 2.00, but the deprecated equivalent db-path has been around since 1.00 and db1-path since 1.06. We could just ignore versions before 2.00 but the same thing has been going on since 2.00 as well.
Given the subtle changes in additional config parameters as each version is released, it may be extremely useful to define the version at which each parameter was introduced.
As an example:
S3 support has been present for a long time, but only recently (v2.38) was S3 KMS support added: https://pgbackrest.org/release.html#2.38
Documenting the 'minimum supported version' in the configuration sections would help to make this much more obvious:
Using the above example, this section https://pgbackrest.org/configuration.html#section-repository/option-repo-s3-kms-key-id would include a
Minimum Version: 2.38
sectionThe text was updated successfully, but these errors were encountered: