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: Tue, 21 Mar 2023 21:32:55 -0700
On Tue, Mar 21, 2023 at 12:40:28PM -0400, Timothe Litt via curl-library wrote:
> I expect that with frequent patch releases, curl would end up in the situation
> of most M$ releases whose strategy is- "wait for the other people to find the
> bugs and only take the nth patch release." And with fewer users, the bugs
> would take longer to turn up...which is a worsening spiral.
That's true, but it's no worse than the situation we have now. I'm
truly hoping that the big distros will continue releasing every version
and not skip the regular releases or there's much less benefit to doing
it this way.
> To make a more frequent patch release scheme work, you'd need to find a group
> of aggressive users/testers who'd find and report bugs early. And be willing
> to take the intermediate releases.
It would be great if we can find more people to test pre-release curl
versions, but my proposal essentially turns everyone who runs the
regularly-scheduled release into such a tester, from a certain point of
view. Some projects that do infrequent release might post an rc1 and
rc2 release to get wider testing before releasing the final version.
curl, embracing the release early, release often mantra and with its
fast pace of development, doesn't really need to do that. Now, I'm
deliberately mischaracterizing the proposal, but you could look at each
regular .0 release as an rc1 and the patch release (if there is one) as
the "real" release. In our case we truly believe based on our tests
that the .0 is production ready and not an RC, but stuff happen.
> And if you can do that, you can also pull them into the regular release
> process...
The kind of things that usually seem to go wrong are the marginal
features that take a large user base to find. I don't know if there
would be enough users in the early testing pools to make a big
difference. If we're only leaving the patch release window open for a
week, there's also not much time for said testers to do their testing
thing. Maybe we should label the daily snapshot one week before a
scheduled release as "rc1" and promote it that way and see what happens?
Dan
Date: Tue, 21 Mar 2023 21:32:55 -0700
On Tue, Mar 21, 2023 at 12:40:28PM -0400, Timothe Litt via curl-library wrote:
> I expect that with frequent patch releases, curl would end up in the situation
> of most M$ releases whose strategy is- "wait for the other people to find the
> bugs and only take the nth patch release." And with fewer users, the bugs
> would take longer to turn up...which is a worsening spiral.
That's true, but it's no worse than the situation we have now. I'm
truly hoping that the big distros will continue releasing every version
and not skip the regular releases or there's much less benefit to doing
it this way.
> To make a more frequent patch release scheme work, you'd need to find a group
> of aggressive users/testers who'd find and report bugs early. And be willing
> to take the intermediate releases.
It would be great if we can find more people to test pre-release curl
versions, but my proposal essentially turns everyone who runs the
regularly-scheduled release into such a tester, from a certain point of
view. Some projects that do infrequent release might post an rc1 and
rc2 release to get wider testing before releasing the final version.
curl, embracing the release early, release often mantra and with its
fast pace of development, doesn't really need to do that. Now, I'm
deliberately mischaracterizing the proposal, but you could look at each
regular .0 release as an rc1 and the patch release (if there is one) as
the "real" release. In our case we truly believe based on our tests
that the .0 is production ready and not an RC, but stuff happen.
> And if you can do that, you can also pull them into the regular release
> process...
The kind of things that usually seem to go wrong are the marginal
features that take a large user base to find. I don't know if there
would be enough users in the early testing pools to make a big
difference. If we're only leaving the patch release window open for a
week, there's also not much time for said testers to do their testing
thing. Maybe we should label the daily snapshot one week before a
scheduled release as "rc1" and promote it that way and see what happens?
Dan
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-03-22