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: Dan Fandrich via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 22 Mar 2023 10:04:11 -0700
On Wed, Mar 22, 2023 at 09:17:48AM +0100, Daniel Stenberg via curl-library wrote:
> 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.
That looks pretty workable to me. The trick is going to be deciding when a
patch release is worthwhile. If we look at git now, 2 days after the last
release, there are already 7 commits. Two are CI adjustments (not
release-worthy), one fixes a problem introduced 9 years ago (not
release-worthy), one improves detection of bugs in debug builds (not
release-worthy) and one improves error detection in testing (not
release-worthy). So far it's pretty easy.
The last two changes fix compile problems in two platforms, OS/400 and Haiku.
Normally, I'd say that would be enough to trigger another release: users can't
build curl when they used to be able to, but these are super marginal
platforms. Are there even a dozen people out there compiling curl for them? If
the situation is such that we could send them all personal e-mails with the
patches then maybe it's not worth doing an entire new release. I really have no
idea how many people there are using this support, though. Haiku's official
curl package is only 6 releases old, so there's some development happening
there. There have also been at least 5 people contributing to OS/400 support
over the last few years, so maybe it's more than a dozen.
Perhaps the answer will be clear in another 8 days.
Dan
Date: Wed, 22 Mar 2023 10:04:11 -0700
On Wed, Mar 22, 2023 at 09:17:48AM +0100, Daniel Stenberg via curl-library wrote:
> 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.
That looks pretty workable to me. The trick is going to be deciding when a
patch release is worthwhile. If we look at git now, 2 days after the last
release, there are already 7 commits. Two are CI adjustments (not
release-worthy), one fixes a problem introduced 9 years ago (not
release-worthy), one improves detection of bugs in debug builds (not
release-worthy) and one improves error detection in testing (not
release-worthy). So far it's pretty easy.
The last two changes fix compile problems in two platforms, OS/400 and Haiku.
Normally, I'd say that would be enough to trigger another release: users can't
build curl when they used to be able to, but these are super marginal
platforms. Are there even a dozen people out there compiling curl for them? If
the situation is such that we could send them all personal e-mails with the
patches then maybe it's not worth doing an entire new release. I really have no
idea how many people there are using this support, though. Haiku's official
curl package is only 6 releases old, so there's some development happening
there. There have also been at least 5 people contributing to OS/400 support
over the last few years, so maybe it's more than a dozen.
Perhaps the answer will be clear in another 8 days.
Dan
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-03-22