1 |
On 9/15/20 9:42 AM, Michał Górny wrote: |
2 |
> Hi, |
3 |
> |
4 |
> The regular stabilization workflow works for the majority of packages. |
5 |
> However, it makes little sense for packages with frequent release |
6 |
> cycles. Examples of these are boto3/botocore (daily release cycle) or |
7 |
> hypothesis (upstream conflates commits with releases). |
8 |
> |
9 |
> When the latest release remains 'latest ~arch' for less than 3 days, |
10 |
> stabilizing it after 30 days makes little sense. After all, people with |
11 |
> frequent upgrade cycle will test it for no more than that, and people |
12 |
> with infrequent upgrade cycle may miss the version entirely. |
13 |
|
14 |
Isn't the 30 days just a recommendation, not a strict rule? |
15 |
|
16 |
|
17 |
> |
18 |
> In the end, we stabilize an entirely arbitrary version at an arbitrary |
19 |
> point in time, and even if users were willing to give it better testing, |
20 |
> they can't guess which version will be the next stable candidate. |
21 |
> |
22 |
> Do you have any suggestions how we could improve this? |
23 |
|
24 |
Just use maintainer's discretion on them. For example, see how |
25 |
youtube-dl and vivaldi are stabilized, both having frequent releases. In |
26 |
vivaldi's case the security updates make fast-stabilization a mandatory |
27 |
step pretty much and for youtube-dl you want to keep it compatible with |
28 |
"today". Anyway, that's one way. |
29 |
|
30 |
Not like every stable version in the tree works either. |
31 |
|
32 |
-- juippis |