Introduce a version number for configuration file(s) format; e.g., version=1 in the first line.
Pros:
Cons:
Additionally, the client can automaGically bump config file version if it complies to the newer one.
Seems like it would defeat the point of deprecating features.
Agree with @luke-jr. Don't think this would change anything, deprecating something would still break support for the old versions of the config file, no matter if it has an explicit version number or provides an option that no longer exists.
Also I think this would be confusing for users and developers alike. Do you have any example of other software which uses configuration versioning—in this sense—successfully?
docker-compose.yml has version. You have to support all versions so it I don't see how it helps with deprecation.
I agree with the above comments, I honestly can't imagine many breaking changes to the .conf files that aren't actually just deprecated arguments, and versioning command line arguments seems like a bad idea. Plus, on the odd occasion that there is a breaking change to the conf files, its usually for a good reason and doesn't have a large impact (e.g. your node will just fail to start until you remove a comment from the file in #14494)
... and versioning command line arguments seems like a bad idea.
You're right. But this discussion is not about command line arguments versioning, rather about config file format versioning.
Also I think this would be confusing for users and developers alike. Do you have any example of other software which uses configuration versioning—in this sense—successfully?
File format versioning (in general) is a common practice. In particular the Electrum Wallet config file has a version (e.g., "config_version": 2).
Consider the issue #13143 as a possible use case:
Current non-versioning (version=0) format allows a comment to start after an option=value pair. That makes the parser to wrong parse a # character within a rpcpassword value.
Assume that version=1 format allows comments to start only from the line beginning. This makes possible to use a # character within a rpcpassword value.
No doubt that previous format versions must be supported during a certain period of time to prevent the breaking support for the old format config files (it will cost 35-40 lines of code per version). And eventually old and deprecated formats support may be dropped.
The future may require more config format improvements and it'll be easy to introduce them with format versioning, IMO.
I think this feature can be added when there is need for it. I don't see a need right now.
Seems like a non-issue for now as mentioned above, closing
@promag sure. @MeshCollider agree.