On 9/15/20 9:42 AM, Michał Górny wrote:
> Hi,
>
> 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.

Isn't the 30 days just a recommendation, not a strict rule?


>
> 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?

Just use maintainer's discretion on them. For example, see how
youtube-dl and vivaldi are stabilized, both having frequent releases. In
vivaldi's case the security updates make fast-stabilization a mandatory
step pretty much and for youtube-dl you want to keep it compatible with
"today". Anyway, that's one way.

Not like every stable version in the tree works either.

-- juippis


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to