Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: On more stable curl releases
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Jeffrey Walton via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 22 Mar 2023 11:02:40 -0400
On Wed, Mar 22, 2023 at 4:17 AM Daniel Stenberg via curl-library
<curl-library_at_lists.haxx.se> wrote:
>
> On Wed, 22 Mar 2023, Stefan Eissing wrote:
>
> > Delaying the opening of the feature window after a release seems to be a
> > good balance. Right now, I have several PRs pending for the re-opening of
> > the window and it does not cost anything to have them wait a week more.
> > Feature branches already exist. Maintenance branches we'd like to avoid.
>
> So, how about this for adjusted release cycle and release management:
>
> - Increase the post-release ("cool down") margin before we open the feature
> window. We currently have it 5 days, we could double it to 10 days. That
> would then reduce the feature window with the same amount of days leaving
> us with 18 days to merge features.
>
> - Within the cool down period, we are only allowed to merge bug-fixes.
>
> - Lower the bar for a patch-release. Even "less important" regressions should
> be considered reason enough to do follow-up releases. And if they are not
> reported within the cool down period, chances are they are not important
> enough.
>
> - After a follow-up release, we start over with a new cool down period of 10
> days.
>
> - If we decide to do a patch release due to a regression, we set that release
> day N days into the future so that we can accumulate a few more fixes and
> get our ducks in order before we ship it. N is probably at least 7.
The last item is the important one due to lack of participation in
pre-release testing. You can ask for testers until you are blue in the
face, but you are only going to get a handful of testers. People won't
test the release until it is released.
To counter the lack of pre-release testing, schedule another release
T+x days after the release of interest. So if you release cURL 8.0.0
on January 1, then you schedule a 8.0.1 maintenance release on January
14 or January 28. You use the 10 days or 2 weeks to clean up the bugs
that crept in but were not caught in pre-release testing.
I don't know how that intersects with the "cool down" or feature
window. I don't use them. In the projects I work with, master is
always hot - it is always in a release state. Feature development and
testing happen in a fork on a branch, so it does not taint master
which is always hot. In fact, because it happens on a fork, it does
not even taint the project itself.
Another person came up with the strategy to counteract the lack of
testers. He told me I would not get enough testers to find the bugs we
hoped to catch before a release. I did not believe him. He was right.
Now I plan for the lack of testers by scheduling a maintenance release
following the release of interest.
Jeff
Date: Wed, 22 Mar 2023 11:02:40 -0400
On Wed, Mar 22, 2023 at 4:17 AM Daniel Stenberg via curl-library
<curl-library_at_lists.haxx.se> wrote:
>
> On Wed, 22 Mar 2023, Stefan Eissing wrote:
>
> > Delaying the opening of the feature window after a release seems to be a
> > good balance. Right now, I have several PRs pending for the re-opening of
> > the window and it does not cost anything to have them wait a week more.
> > Feature branches already exist. Maintenance branches we'd like to avoid.
>
> So, how about this for adjusted release cycle and release management:
>
> - Increase the post-release ("cool down") margin before we open the feature
> window. We currently have it 5 days, we could double it to 10 days. That
> would then reduce the feature window with the same amount of days leaving
> us with 18 days to merge features.
>
> - Within the cool down period, we are only allowed to merge bug-fixes.
>
> - Lower the bar for a patch-release. Even "less important" regressions should
> be considered reason enough to do follow-up releases. And if they are not
> reported within the cool down period, chances are they are not important
> enough.
>
> - After a follow-up release, we start over with a new cool down period of 10
> days.
>
> - If we decide to do a patch release due to a regression, we set that release
> day N days into the future so that we can accumulate a few more fixes and
> get our ducks in order before we ship it. N is probably at least 7.
The last item is the important one due to lack of participation in
pre-release testing. You can ask for testers until you are blue in the
face, but you are only going to get a handful of testers. People won't
test the release until it is released.
To counter the lack of pre-release testing, schedule another release
T+x days after the release of interest. So if you release cURL 8.0.0
on January 1, then you schedule a 8.0.1 maintenance release on January
14 or January 28. You use the 10 days or 2 weeks to clean up the bugs
that crept in but were not caught in pre-release testing.
I don't know how that intersects with the "cool down" or feature
window. I don't use them. In the projects I work with, master is
always hot - it is always in a release state. Feature development and
testing happen in a fork on a branch, so it does not taint master
which is always hot. In fact, because it happens on a fork, it does
not even taint the project itself.
Another person came up with the strategy to counteract the lack of
testers. He told me I would not get enough testers to find the bugs we
hoped to catch before a release. I did not believe him. He was right.
Now I plan for the lack of testers by scheduling a maintenance release
following the release of interest.
Jeff
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-03-22