On 01/05/2018 11:47 PM, Kristian Fiskerstrand wrote:
> On 01/05/2018 11:40 PM, Alec Warner wrote:
>>> I might sound like a broken CD here, but why define the expiration as
>>> part of the news format instead of specifying it in the package manager
>>> as a user defined variable? Various use cases requires different
>>> treatment, so leaving it up to user seems more relevant to me, and we
>>> could allow information to be presented as part of stages to give a hint
>>> for what dates to look for?
>> The short answer is I haven't seen any real use cases for it and even if we
>> were to spec it out and add it, I don't think it would be used by more than
>> 10 people. To me that is an incentive to avoid complicating the software
>> spec.
> From my point of view it requires less specification, as it doesn't
> require a policy for how to set the expiration date, but allowing some
> flexibility on the part of the user base.
> There are rather big differences e.g between a server upgrade pattern
> and a desktop system, how would you account for that in the expire date?
> in particular for non security relevant upgrades, e.g profile changes?

Lets take another real-life example; I have two machines A and B. A is
one a stage3 install from before switching from 13.0. to 17.0 and B is
on the latter. As a developer, how would you specify expiration for
switch between profiles?

Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to