> On 24 Jul 2023, at 00:19, Pavel Korovin <p...@tristero.se> wrote:
>
> On 07/23, Stuart Henderson wrote:
>> On 2023/07/23 16:05, Pavel Korovin wrote:
>>> I think adding @ask-update makes sense only if there's an UPGRADE section in
>>> README describing what setting is deprecated in which version, otherwise
>>> I'll end up with multiple @ask-update for each version, or with @ask-update
>>> for all versions with something misleading like: "check your config for
>>> deprecated settings", but how people will know what's deprecated?
>>
>> Users can't see a new pkg-readme on the running system until they've
>> already agreed to accept the update.
>
> Oops then, my bad :)
>
>> IMHO I would go with 4) - 1) and a short pkg/MESSAGE "if updating from
>> before X.Y, see the pkg-readme for config options which are no longer
>> supported". ("deprecated" is "still work but you should stop using them"
>> rather than "no longer works and things break unless you remove them").
>>
>> As I see it, @ask-update is mostly needed where you need to take steps
>> _before_ the new version is installed (say, for postgresql if you're in
>> a situation where you can't use pg_upgrade, e.g. using an extension,
>> you need to run the old version in order to dump the db), Whereas if
>> it's steps to be taken after updating, it doesn't really matter if
>> people update first, they can still follow them.
>
> I'm OK with your approach, the only thing which makes me feel bad is
> the situation when the user runs 'pkg_add -u' and then finds that gitea
> fails to start and something has to be done now to fix it.
Using MESSAGE makes sense if upstream notifies of upcoming removals pending
deprecation.
I.e. if they deprecate an option but don’t actually error out on it?
> --
> With best regards,
> Pavel Korovin
