Dnscrypt-proxy: Should the next version be 2.1.0?

[jedisct1]

This is just a cosmetic question. After 44 versions dnscrypt-proxy has changed quite a lot since the initial release.

Besides bug fixes and performance improvements, tons of features have been introduced, and current versions look like a very different app compared to version 2.0.0.

The next release is going to encourage, or require minor configuration changes (black/white renaming, move the v3 list URLs). It may also be a good opportunity to remove previous backward compatibility layers for configuration options that have long been deprecated or renamed. Such changes are more expected after a major version bump rather than in a version that feels like yet another incremental release.

On the other hand, there won't be any significant new features or changes as one may expect from a major version change.

What do you people think?

@alisonatwork @ianbashford @welwood08 @hugepants @lifenjoiner @IceCodeNew @kev-null

[welwood08]

I'd say every release that might cause running configurations to stop working and require manual intervention should increment a more significant version part than usual, to set appropriate user expectations when updating.

This probably should have been considered more carefully with the renaming of tls_client_auth to doh_client_x509_auth for example. I do agree with using a more significant version bump as an opportunity to clean up all previous deprecations and transition layers, otherwise there's a risk they remain around forever.

While I'd normally combine this sort of version increment with a headline feature of some kind, version numbers are plentiful and if there are external reasons to prioritise a release then a headline feature need not be a requirement.

[alisonatwork]

I have a feeling that a lot of people are keeping dnscrypt-proxy up-to-date with a package manager, so they don't really care about the version number, they just trust that the upgrade isn't going to break their existing config.

I think it makes sense to do a larger version bump if we remove old config options, since that is at least somewhat of a hint to the package maintainers that they might need to do a bit of extra work to make the upgrade clean. We could help them out by providing a script to read in an old config and write out a new one, although i guess we'd still be dependent on them to add that to their package's post-install step... and that's assuming they're even comfortable automatically rewriting their users' configs. Another option would be for dnscrypt-proxy itself to automatically upgrade the config file, but that feels like adding complexity that really should belong in the package manager.

Perhaps it's worth releasing one more backward compatible version first that includes warning logs for all the deprecated options, then remove all the old options in 2.1.0 and improve the behavior of the unknown config handling.

How could we improve? Right now when we encounter an unknown config we print Unsupported key in configuration file and quit, but because this happens before the logging gets properly set up, users who are using syslog or a log file may not see the message letting them know there was something wrong. Moving that error a bit later and adding some more context could be helpful. For example, we could say that certain config keys were removed in 2.1.0, and provide a pointer to the last 2.0.x so users can choose to downgrade and pin it if they don't have time to upgrade their file then-and-there.

[ianbashford]

+1 to (at least) one more patch release that maintains backwards compatibility, then using a minor release to make the breaks.
(I liked the approach (maybe spring or spring-boot) where versioning is 'pain' rather than only 'feature' oriented -- patch numbers should be drop in replacement - minor numbers should be an easy upgrade, but might require some work; major versions might break stuff ).
The packaging is also an interesting thought (I maintain the Alpine package). Each release, a new vanilla config file is written alongside the live config file (with an apk-new suffix). Running a script to detect deprecated keys and writing out an additional updated file would be a good upgrade feature.

[lifenjoiner]

There are plenty of numbers left ... Thinking of Chrome, Firefox ... :smile:

Bump the minor version to remind people of some changes is reasonable. It reminds users to read the release notes.

I use a diffmerge software comparing the new config file and mine, then apply my mod to the new one every time.

[IceCodeNew]

I think it makes sense to do a larger version bump if we remove old config options, since that is at least somewhat of a hint to the package maintainers that they might need to do a bit of extra work to make the upgrade clean.

+1

Perhaps it's worth releasing one more backward compatible version first that includes warning logs for all the deprecated options, then remove all the old options in 2.1.0 and improve the behavior of the unknown config handling.

Can't agree more.

[alisonatwork]

Here's a PR that implements the change I suggested to how we parse the config file: https://github.com/DNSCrypt/dnscrypt-proxy/pull/1426

The functional change there is that we initialize syslog or the log file as soon as possible before reporting any errors in the config file format. Hopefully this will make it easier for people running Windows or systemd service to understand what went wrong if they upgrade to a backward-incompatible version.

[alisonatwork]

I wonder if we should also restore the backwards-compatible behavior of tls_client_auth for one more release in the 2.0.x series (2.0.45) before properly removing it in 2.1.0? Right now config files with tls_client_auth from 2.0.40 to 2.0.42 will fatal error on 2.0.43 and 2.0.44 (maybe not a big deal since the exposure was only a couple months).

[jedisct1]

Keeping support for tls_client_auth is probably not necessary. People running >=2.0.43 already have an updated configuration.

[jedisct1]

Alright. One more 2.0.x version before 2.1.0 then!

Thanks a ton for your input!