Buy commercial curl support. 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 Daniel himself.
RE: Help us out in the curl project
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 6 Feb 2025 09:21:30 +0100 (CET)
On Wed, 5 Feb 2025, Marcel Raad via curl-library wrote:
> I think testing the first daily snapshot after the feature window closes
> would be ideal, as most possibly breaking changes happen before that.
Agreed,
I had a sitdown at FOSDEM with the good people maintaining curl on Debian and
with some brainstorming on the topic I think we can start easy and do this:
1. I create an official release candidate one (rc1) when we enter feature
freeze. It would be the first tarball we would appreciate if people tested to
make sure no regressions or other sillyness have crept in. No git tag will be
set for this.
It will then be hosted somewhere for a few weeks until removed again.
2. I create a second release candidate (rc2) two weeks before the expected
release date the exact same way as the rc1. This will contain more fixes, but
if anyone finds problems in this there is still some time left in the cycle to
fix things before the release.
This is a low maintenance take and does not impose hard work on anyone. It
offers a unified take and offer some snapshots and times where extra testing
is encouraged.
My plan is to start with this in this release cycle.
Date: Thu, 6 Feb 2025 09:21:30 +0100 (CET)
On Wed, 5 Feb 2025, Marcel Raad via curl-library wrote:
> I think testing the first daily snapshot after the feature window closes
> would be ideal, as most possibly breaking changes happen before that.
Agreed,
I had a sitdown at FOSDEM with the good people maintaining curl on Debian and
with some brainstorming on the topic I think we can start easy and do this:
1. I create an official release candidate one (rc1) when we enter feature
freeze. It would be the first tarball we would appreciate if people tested to
make sure no regressions or other sillyness have crept in. No git tag will be
set for this.
It will then be hosted somewhere for a few weeks until removed again.
2. I create a second release candidate (rc2) two weeks before the expected
release date the exact same way as the rc1. This will contain more fixes, but
if anyone finds problems in this there is still some time left in the cycle to
fix things before the release.
This is a low maintenance take and does not impose hard work on anyone. It
offers a unified take and offer some snapshots and times where extra testing
is encouraged.
My plan is to start with this in this release cycle.
-- / daniel.haxx.se || https://rock-solid.curl.dev -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-02-06