|
Notes |
|
|
|
I'd just leave this as "won't fix", personally. Not a lot to gain from bloating the code base further and dealing with configuration merges (both upgrading and downgrading).
Anyone else want to comment on this? |
|
|
|
|
|
What I'd rather do is document in some NEWS file about configuration changes that should be done by the user when upgrading. |
|
|
|
|
|
|
|
(0020758)
|
|
Zalewa
|
|
2019-06-13 15:03
|
|
There's a "Always use Wadseeker's default sites" checkbox in the "Wadseeker/Sites" config page. If it's checked, Wadseeker will always use the up-to-date hardcoded sites, no matter what's on the list in the config page. If the checkbox is unchecked, only the sites listed on the page are used.
The "Wadseeker/Sites" listing is deliberately left to total control of the user. It's only initialized with the default sites when the config file is first created and then it isn't touched anymore. This was done by design to allow people to control what sites are being contacted in case if some sites stop working and there's no new Wadseeker release to remove them from the list. This removes the necessity to do a new Wadseeker release whenever some page goes 404.
Config auto-migration would strip the control from the user and it'd be prone to causing mistakes or not working exactly correctly if user had modified the site's list by hand.
I think the current options are sufficient to let everyone manage Wadseeker's sites list however they want.
In short: I agree on "won't fix". |
|
|
|
(0020760)
|
|
Pol M
|
|
2019-06-13 16:28
|
|
|
Based on Zalewa's comment, I completely agree on "won't fix" |
|