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
signature.asc
Description: OpenPGP digital signature
