1 |
Hi, |
2 |
|
3 |
The regular stabilization workflow works for the majority of packages. |
4 |
However, it makes little sense for packages with frequent release |
5 |
cycles. Examples of these are boto3/botocore (daily release cycle) or |
6 |
hypothesis (upstream conflates commits with releases). |
7 |
|
8 |
When the latest release remains 'latest ~arch' for less than 3 days, |
9 |
stabilizing it after 30 days makes little sense. After all, people with |
10 |
frequent upgrade cycle will test it for no more than that, and people |
11 |
with infrequent upgrade cycle may miss the version entirely. |
12 |
|
13 |
In the end, we stabilize an entirely arbitrary version at an arbitrary |
14 |
point in time, and even if users were willing to give it better testing, |
15 |
they can't guess which version will be the next stable candidate. |
16 |
|
17 |
Do you have any suggestions how we could improve this? |
18 |
|
19 |
-- |
20 |
Best regards, |
21 |
Michał Górny |