The regular stabilization workflow works for the majority of packages.
 However, it makes little sense for packages with frequent release
cycles.  Examples of these are boto3/botocore (daily release cycle) or
hypothesis (upstream conflates commits with releases).

When the latest release remains 'latest ~arch' for less than 3 days,
stabilizing it after 30 days makes little sense.  After all, people with
frequent upgrade cycle will test it for no more than that, and people
with infrequent upgrade cycle may miss the version entirely.

In the end, we stabilize an entirely arbitrary version at an arbitrary
point in time, and even if users were willing to give it better testing,
they can't guess which version will be the next stable candidate.

Do you have any suggestions how we could improve this?

Best regards,
Michał Górny

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to