You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@serf.apache.org by Daniel Sahlberg <da...@gmail.com> on 2025/06/27 09:42:59 UTC
Releasing 1.4
Hi,
I'm very happy to see the rekindled interest in Serf development and the
recent work by Brane on the user-defined-authn branch and by Graham on the
OpenSSL "certificate by URI" PR. I'm planning on reviewing those things
during the weekend. When these are merged (and it doesn't only depend on
me, it is of course a team effort reviewing and merging!) we should start
thinking about a new release.
I don't think it makes sense to backport to 1.3 - they would add new APIs
that require a version bump.
The existing 1.4.x branch was created in 2018 and received a few backports
the same year but it lacks significant work from trunk, for example
Evgeny's OpenSSL3 work in 2022 that led up to the release of 1.3.10.
I'm proposing to drop the current 1.4.x branch and create a new one based
on trunk. Alternative option to drop 1.4.x completely and instead name the
new release 1.5.
As far as I understand trunk contains a bunch of HTTP 2-work, but according
to Brane earlier on dev@ some is hidden behind #ifdefs that will only
expose it if released as Serf 2. Would it make sense to get this released
as well? In that case, should we instead aim for Serf 2.0? Alternative
option to remove the #ifdefs and declare it stable in Serf 1.
Cheers,
Daniel
Re: Releasing 1.4
Posted by Branko Čibej <br...@apache.org>.
On 27. 6. 25 11:42, Daniel Sahlberg wrote:
> As far as I understand trunk contains a bunch of HTTP 2-work, but according
> to Brane earlier on dev@ some is hidden behind #ifdefs that will only
> expose it if released as Serf 2. Would it make sense to get this released
> as well? In that case, should we instead aim for Serf 2.0? Alternative
> option to remove the #ifdefs and declare it stable in Serf 1.
It's not #ifdef, it's #if 0. I have no idea what the status of these new
APIs is, or what they're even for. Greg should chime in, it "blame" says
he added most of that. But it's clearly incomplete and nowhere near
ready for a release.
-- Brane
Re: Releasing 1.`s/4/5/g`
Posted by Branko Čibej <br...@apache.org>.
On 27. 6. 25 11:42, Daniel Sahlberg wrote:
> Hi,
>
> I'm very happy to see the rekindled interest in Serf development and the
> recent work by Brane on the user-defined-authn branch and by Graham on the
> OpenSSL "certificate by URI" PR. I'm planning on reviewing those things
> during the weekend. When these are merged (and it doesn't only depend on
> me, it is of course a team effort reviewing and merging!) we should start
> thinking about a new release.
>
> I don't think it makes sense to backport to 1.3 - they would add new APIs
> that require a version bump.
>
> The existing 1.4.x branch was created in 2018 and received a few backports
> the same year but it lacks significant work from trunk, for example
> Evgeny's OpenSSL3 work in 2022 that led up to the release of 1.3.10.
>
> I'm proposing to drop the current 1.4.x branch and create a new one based
> on trunk. Alternative option to drop 1.4.x completely and instead name the
> new release 1.5.
>
> As far as I understand trunk contains a bunch of HTTP 2-work, but according
> to Brane earlier on dev@ some is hidden behind #ifdefs that will only
> expose it if released as Serf 2. Would it make sense to get this released
> as well? In that case, should we instead aim for Serf 2.0? Alternative
> option to remove the #ifdefs and declare it stable in Serf 1.
>
> Cheers,
> Daniel
>
I made some assumptions and started
https://issues.apache.org/jira/browse/SERF-208
-- Brane
Re: Releasing 1.4
Posted by Branko Čibej <br...@apache.org>.
On 30. 6. 25 10:34, Graham Leggett wrote:
> On 29 Jun 2025, at 11:45, Branko Čibej<br...@apache.org> wrote:
>
>>> I pulled apart svn, and the svn_error_t structure has a nested characteristic that makes it perfect for adding extra detail where extra detail is needed.
>> Yup. It's a stack of errors, and/or tracing messages.
>>
>>> Over the next few days I hope to have something that works.
>> Did you intend to add something svn_error_t/stack-like to Serf, or do this some other way? I know Serf uses bitmasks, but that seems quite limited.
> My gut feel was a callback of some kind.
>
> "If you care, I (serf) have called you (svn) with a string containing details of an underlying error, do with it what you will".
>
> Neither serf nor svn has to attach any underlying significance to the string, it's just extra detail.
+1
Re: Releasing 1.4
Posted by Nathan Hartman <ha...@gmail.com>.
On Mon, Jun 30, 2025 at 4:52 PM Greg Stein <gs...@gmail.com> wrote:
> A callback to provide error information? Is that what you're really
> suggesting?
>
> Think of the implications of that. A serf function is called. It runs into
> a problem. It calls back and the app places the additional information ...
> where? Kind of some global thing? Then the serf function returns an error
> code to the app. Then the app says "oh. maybe there is more info. let me go
> look in the global variables"
>
> No. That is terrible dataflow. Please explain what you mean ... something
> other than the nightmare above.
>
> The svn_error_t structure and its functionality exists as a core feature of
> the svn codebase. It is fully-integrated throughout. Serf was not designed
> with that pattern, for better or worse.
>
> Thanks,
> -g
>
I assume you're talking about PR-9 [1].
I agree a callback for error reporting is not an ideal dataflow, but
since, as you point out, Serf was not designed with the pattern used
in the SVN codebase, the only ideal way to fix this is to go back in
time and design it that way from the start. Something tells me that
might not be feasible. :-)
Though this isn't ideal, the benefit to users and administrators is
huge. When there's an error related to network problems, it helps
tremendously to have more specific information than "I'm very sorry,
Dave, I'm afraid I can't do that." [2]
Ostensibly the application (e.g., Subversion) would *not* store error
information in some global. The application does get a chance to set a
callback context ("baton" in the proposed serf_ssl_error_cb_set() in
the PR). So the error would go someplace appropriate that is related
to whatever the application is doing at the time.
Unless anyone has a better way to offer, I think the idea presented
there is worthwhile.
[1] https://github.com/apache/serf/pull/9
[2] https://en.wikipedia.org/wiki/2001:_A_Space_Odyssey
Re: Releasing 1.4
Posted by Greg Stein <gs...@gmail.com>.
A callback to provide error information? Is that what you're really
suggesting?
Think of the implications of that. A serf function is called. It runs into
a problem. It calls back and the app places the additional information ...
where? Kind of some global thing? Then the serf function returns an error
code to the app. Then the app says "oh. maybe there is more info. let me go
look in the global variables"
No. That is terrible dataflow. Please explain what you mean ... something
other than the nightmare above.
The svn_error_t structure and its functionality exists as a core feature of
the svn codebase. It is fully-integrated throughout. Serf was not designed
with that pattern, for better or worse.
Thanks,
-g
On Mon, Jun 30, 2025 at 3:34 AM Graham Leggett <mi...@sharp.fm.invalid>
wrote:
> On 29 Jun 2025, at 11:45, Branko Čibej <br...@apache.org> wrote:
>
> >> I pulled apart svn, and the svn_error_t structure has a nested
> characteristic that makes it perfect for adding extra detail where extra
> detail is needed.
> >
> > Yup. It's a stack of errors, and/or tracing messages.
> >
> >> Over the next few days I hope to have something that works.
> >
> > Did you intend to add something svn_error_t/stack-like to Serf, or do
> this some other way? I know Serf uses bitmasks, but that seems quite
> limited.
>
> My gut feel was a callback of some kind.
>
> "If you care, I (serf) have called you (svn) with a string containing
> details of an underlying error, do with it what you will".
>
> Neither serf nor svn has to attach any underlying significance to the
> string, it's just extra detail.
>
> Regards,
> Graham
> --
>
>
Re: Releasing 1.4
Posted by Graham Leggett <mi...@sharp.fm.INVALID>.
On 29 Jun 2025, at 11:45, Branko Čibej <br...@apache.org> wrote:
>> I pulled apart svn, and the svn_error_t structure has a nested characteristic that makes it perfect for adding extra detail where extra detail is needed.
>
> Yup. It's a stack of errors, and/or tracing messages.
>
>> Over the next few days I hope to have something that works.
>
> Did you intend to add something svn_error_t/stack-like to Serf, or do this some other way? I know Serf uses bitmasks, but that seems quite limited.
My gut feel was a callback of some kind.
"If you care, I (serf) have called you (svn) with a string containing details of an underlying error, do with it what you will".
Neither serf nor svn has to attach any underlying significance to the string, it's just extra detail.
Regards,
Graham
--
Re: Releasing 1.4
Posted by Branko Čibej <br...@apache.org>.
On 29. 6. 25 11:49, Graham Leggett wrote:
> On 27 Jun 2025, at 10:42, Daniel Sahlberg<da...@gmail.com> wrote:
>
>> I'm very happy to see the rekindled interest in Serf development and the
>> recent work by Brane on the user-defined-authn branch and by Graham on the
>> OpenSSL "certificate by URI" PR. I'm planning on reviewing those things
>> during the weekend. When these are merged (and it doesn't only depend on
>> me, it is of course a team effort reviewing and merging!) we should start
>> thinking about a new release.
> I am keen to solve the error handling problem - anything SSL related needs to expose the exact underlying reason for whatever failure happened.
>
> I pulled apart svn, and the svn_error_t structure has a nested characteristic that makes it perfect for adding extra detail where extra detail is needed.
Yup. It's a stack of errors, and/or tracing messages.
> Over the next few days I hope to have something that works.
Did you intend to add something svn_error_t/stack-like to Serf, or do
this some other way? I know Serf uses bitmasks, but that seems quite
limited.
-- Brane
Re: Releasing 1.4
Posted by Graham Leggett <mi...@sharp.fm.INVALID>.
On 27 Jun 2025, at 10:42, Daniel Sahlberg <da...@gmail.com> wrote:
> I'm very happy to see the rekindled interest in Serf development and the
> recent work by Brane on the user-defined-authn branch and by Graham on the
> OpenSSL "certificate by URI" PR. I'm planning on reviewing those things
> during the weekend. When these are merged (and it doesn't only depend on
> me, it is of course a team effort reviewing and merging!) we should start
> thinking about a new release.
I am keen to solve the error handling problem - anything SSL related needs to expose the exact underlying reason for whatever failure happened.
I pulled apart svn, and the svn_error_t structure has a nested characteristic that makes it perfect for adding extra detail where extra detail is needed.
Over the next few days I hope to have something that works.
Regards,
Graham
--
Re: Releasing 1.4
Posted by Branko Čibej <br...@apache.org>.
On 1. 7. 25 15:32, Peter Balogh wrote:
>
> Best regards,
> Peter
>
> On 2025. 07. 01. 0:20, Branko Čibej wrote:
>> On 30. 6. 25 23:35, Peter Balogh wrote:
>>> Hi,
>>>
>>> If it helps, I've just downloaded two repos, one over 4GB without
>>> issue, both https, windows debug build, serf user-defined-authn branch
>>
>> Which platform?
> Windows x64 Debug using Visual Studio
Hm. So if this is specific to macOS, then I'm inclined to suspect it's
related to https://issues.apache.org/jira/browse/SERF-209 ...
-- Brane
Re: Releasing 1.4
Posted by Peter Balogh <pe...@svnplus.com>.
Best regards,
Peter
On 2025. 07. 01. 0:20, Branko Čibej wrote:
> On 30. 6. 25 23:35, Peter Balogh wrote:
>> Hi,
>>
>> If it helps, I've just downloaded two repos, one over 4GB without
>> issue, both https, windows debug build, serf user-defined-authn branch
>
> Which platform?
Windows x64 Debug using Visual Studio
>
>
>> Also can I hope to get user-defined-authn in the next release? :)
>> It's working fine so far for my purposes
>
> That's the idea, but the branch has not been reviewed yet.
>
> -- Brane
>
>
>> On 2025. 06. 29. 21:03, Branko Čibej wrote:
>>> On 29. 6. 25 09:41, Branko Čibej wrote:
>>>> On 27. 6. 25 11:42, Daniel Sahlberg wrote:
>>>>> Hi,
>>>>>
>>>>> I'm very happy to see the rekindled interest in Serf development
>>>>> and the
>>>>> recent work by Brane on the user-defined-authn branch and by
>>>>> Graham on the
>>>>> OpenSSL "certificate by URI" PR. I'm planning on reviewing those
>>>>> things
>>>>> during the weekend. When these are merged (and it doesn't only
>>>>> depend on
>>>>> me, it is of course a team effort reviewing and merging!) we
>>>>> should start
>>>>> thinking about a new release.
>>>>>
>>>>> I don't think it makes sense to backport to 1.3 - they would add
>>>>> new APIs
>>>>> that require a version bump.
>>>>>
>>>>> The existing 1.4.x branch was created in 2018 and received a few
>>>>> backports
>>>>> the same year but it lacks significant work from trunk, for example
>>>>> Evgeny's OpenSSL3 work in 2022 that led up to the release of 1.3.10.
>>>>>
>>>>> I'm proposing to drop the current 1.4.x branch and create a new
>>>>> one based
>>>>> on trunk. Alternative option to drop 1.4.x completely and instead
>>>>> name the
>>>>> new release 1.5.
>>>>
>>>> I'm inclined towards calling the next release 1.5 and retiring
>>>> 1.4.x. There are so many changes on trunk that have not been
>>>> backported that it would amount to the same thing -- a wholesale
>>>> merge from trunk. Gathering all the backport proposals into STATUS
>>>> and then voting on each one would take longer than validating that
>>>> trunk is stable.
>>>>
>>>> I've been testing serf-trunk with subversion-trunk and all seems
>>>> fine. There are new features that Subversion doesn't use
>>>> (specifically, the OCSP stuff for validating certificates -- but,
>>>> AFAIK, that's still live somewhere else). Whether or not they pick
>>>> this up is really not a question we have to solve before releasing.
>>>
>>> I take that back. I just tried a checkout of the Subversion repo
>>> with serf-trunk via HTTPS. Crashes in SSL_CTX_new(), with OpenSSL
>>> 3.5.0, works fine over HTTP. This is not cool. I hope I didn't
>>> introduce a fine bug with some of my recent changes.
>>>
>>> Ah well. This all goes towards stabilising trunk.
>>>
>>> -- Brane
>>>
>
Re: Releasing 1.4
Posted by Branko Čibej <br...@apache.org>.
On 30. 6. 25 23:35, Peter Balogh wrote:
> Hi,
>
> If it helps, I've just downloaded two repos, one over 4GB without
> issue, both https, windows debug build, serf user-defined-authn branch
Which platform?
> Also can I hope to get user-defined-authn in the next release? :)
> It's working fine so far for my purposes
That's the idea, but the branch has not been reviewed yet.
-- Brane
> On 2025. 06. 29. 21:03, Branko Čibej wrote:
>> On 29. 6. 25 09:41, Branko Čibej wrote:
>>> On 27. 6. 25 11:42, Daniel Sahlberg wrote:
>>>> Hi,
>>>>
>>>> I'm very happy to see the rekindled interest in Serf development
>>>> and the
>>>> recent work by Brane on the user-defined-authn branch and by Graham
>>>> on the
>>>> OpenSSL "certificate by URI" PR. I'm planning on reviewing those
>>>> things
>>>> during the weekend. When these are merged (and it doesn't only
>>>> depend on
>>>> me, it is of course a team effort reviewing and merging!) we should
>>>> start
>>>> thinking about a new release.
>>>>
>>>> I don't think it makes sense to backport to 1.3 - they would add
>>>> new APIs
>>>> that require a version bump.
>>>>
>>>> The existing 1.4.x branch was created in 2018 and received a few
>>>> backports
>>>> the same year but it lacks significant work from trunk, for example
>>>> Evgeny's OpenSSL3 work in 2022 that led up to the release of 1.3.10.
>>>>
>>>> I'm proposing to drop the current 1.4.x branch and create a new one
>>>> based
>>>> on trunk. Alternative option to drop 1.4.x completely and instead
>>>> name the
>>>> new release 1.5.
>>>
>>> I'm inclined towards calling the next release 1.5 and retiring
>>> 1.4.x. There are so many changes on trunk that have not been
>>> backported that it would amount to the same thing -- a wholesale
>>> merge from trunk. Gathering all the backport proposals into STATUS
>>> and then voting on each one would take longer than validating that
>>> trunk is stable.
>>>
>>> I've been testing serf-trunk with subversion-trunk and all seems
>>> fine. There are new features that Subversion doesn't use
>>> (specifically, the OCSP stuff for validating certificates -- but,
>>> AFAIK, that's still live somewhere else). Whether or not they pick
>>> this up is really not a question we have to solve before releasing.
>>
>> I take that back. I just tried a checkout of the Subversion repo with
>> serf-trunk via HTTPS. Crashes in SSL_CTX_new(), with OpenSSL 3.5.0,
>> works fine over HTTP. This is not cool. I hope I didn't introduce a
>> fine bug with some of my recent changes.
>>
>> Ah well. This all goes towards stabilising trunk.
>>
>> -- Brane
>>
Re: Releasing 1.4
Posted by Branko Čibej <br...@apache.org>.
On 1. 7. 25 15:33, Peter Balogh wrote:
> Hi,
>
> The current code is just a PoC, I'm working on the server side at the
> moment
> As soon as I have anything worth looking at, I'll share what I have
>
> Best regards,
> Peter
As a matter of fact, proofs-of-concept are usually worth looking at, if
only catch problems sooner. On top of everything else, you're dealing
with HTTP semantics, which tends to be tricky.
> On 2025. 07. 01. 10:26, Daniel Sahlberg wrote:
>> Hi,
>>
>> Have you started looking at using the new APIs? Any chance you can
>> share the code?
>>
>> Cheers,
>> Daniel
>>
>>
>> Den mån 30 juni 2025 kl 23:36 skrev Peter Balogh <pe...@svnplus.com>:
>>
>> Hi,
>>
>> If it helps, I've just downloaded two repos, one over 4GB without
>> issue,
>> both https, windows debug build, serf user-defined-authn branch
>> Also can I hope to get user-defined-authn in the next release? :)
>> It's working fine so far for my purposes
>>
>> Best regards,
>> Peter
>>
>> On 2025. 06. 29. 21:03, Branko Čibej wrote:
>> > On 29. 6. 25 09:41, Branko Čibej wrote:
>> >> On 27. 6. 25 11:42, Daniel Sahlberg wrote:
>> >>> Hi,
>> >>>
>> >>> I'm very happy to see the rekindled interest in Serf
>> development and
>> >>> the
>> >>> recent work by Brane on the user-defined-authn branch and by
>> Graham
>> >>> on the
>> >>> OpenSSL "certificate by URI" PR. I'm planning on reviewing
>> those things
>> >>> during the weekend. When these are merged (and it doesn't only
>> >>> depend on
>> >>> me, it is of course a team effort reviewing and merging!) we
>> should
>> >>> start
>> >>> thinking about a new release.
>> >>>
>> >>> I don't think it makes sense to backport to 1.3 - they would
>> add new
>> >>> APIs
>> >>> that require a version bump.
>> >>>
>> >>> The existing 1.4.x branch was created in 2018 and received a few
>> >>> backports
>> >>> the same year but it lacks significant work from trunk, for
>> example
>> >>> Evgeny's OpenSSL3 work in 2022 that led up to the release of
>> 1.3.10.
>> >>>
>> >>> I'm proposing to drop the current 1.4.x branch and create a
>> new one
>> >>> based
>> >>> on trunk. Alternative option to drop 1.4.x completely and
>> instead
>> >>> name the
>> >>> new release 1.5.
>> >>
>> >> I'm inclined towards calling the next release 1.5 and retiring
>> 1.4.x.
>> >> There are so many changes on trunk that have not been
>> backported that
>> >> it would amount to the same thing -- a wholesale merge from
>> trunk.
>> >> Gathering all the backport proposals into STATUS and then
>> voting on
>> >> each one would take longer than validating that trunk is stable.
>> >>
>> >> I've been testing serf-trunk with subversion-trunk and all seems
>> >> fine. There are new features that Subversion doesn't use
>> >> (specifically, the OCSP stuff for validating certificates -- but,
>> >> AFAIK, that's still live somewhere else). Whether or not they
>> pick
>> >> this up is really not a question we have to solve before
>> releasing.
>> >
>> > I take that back. I just tried a checkout of the Subversion repo
>> with
>> > serf-trunk via HTTPS. Crashes in SSL_CTX_new(), with OpenSSL
>> 3.5.0,
>> > works fine over HTTP. This is not cool. I hope I didn't
>> introduce a
>> > fine bug with some of my recent changes.
>> >
>> > Ah well. This all goes towards stabilising trunk.
>> >
>> > -- Brane
>> >
>>
Re: Releasing 1.4
Posted by Peter Balogh <pe...@svnplus.com>.
Hi,
The current code is just a PoC, I'm working on the server side at the moment
As soon as I have anything worth looking at, I'll share what I have
Best regards,
Peter
On 2025. 07. 01. 10:26, Daniel Sahlberg wrote:
> Hi,
>
> Have you started looking at using the new APIs? Any chance you can
> share the code?
>
> Cheers,
> Daniel
>
>
> Den mån 30 juni 2025 kl 23:36 skrev Peter Balogh <pe...@svnplus.com>:
>
> Hi,
>
> If it helps, I've just downloaded two repos, one over 4GB without
> issue,
> both https, windows debug build, serf user-defined-authn branch
> Also can I hope to get user-defined-authn in the next release? :)
> It's working fine so far for my purposes
>
> Best regards,
> Peter
>
> On 2025. 06. 29. 21:03, Branko Čibej wrote:
> > On 29. 6. 25 09:41, Branko Čibej wrote:
> >> On 27. 6. 25 11:42, Daniel Sahlberg wrote:
> >>> Hi,
> >>>
> >>> I'm very happy to see the rekindled interest in Serf
> development and
> >>> the
> >>> recent work by Brane on the user-defined-authn branch and by
> Graham
> >>> on the
> >>> OpenSSL "certificate by URI" PR. I'm planning on reviewing
> those things
> >>> during the weekend. When these are merged (and it doesn't only
> >>> depend on
> >>> me, it is of course a team effort reviewing and merging!) we
> should
> >>> start
> >>> thinking about a new release.
> >>>
> >>> I don't think it makes sense to backport to 1.3 - they would
> add new
> >>> APIs
> >>> that require a version bump.
> >>>
> >>> The existing 1.4.x branch was created in 2018 and received a few
> >>> backports
> >>> the same year but it lacks significant work from trunk, for
> example
> >>> Evgeny's OpenSSL3 work in 2022 that led up to the release of
> 1.3.10.
> >>>
> >>> I'm proposing to drop the current 1.4.x branch and create a
> new one
> >>> based
> >>> on trunk. Alternative option to drop 1.4.x completely and instead
> >>> name the
> >>> new release 1.5.
> >>
> >> I'm inclined towards calling the next release 1.5 and retiring
> 1.4.x.
> >> There are so many changes on trunk that have not been
> backported that
> >> it would amount to the same thing -- a wholesale merge from trunk.
> >> Gathering all the backport proposals into STATUS and then
> voting on
> >> each one would take longer than validating that trunk is stable.
> >>
> >> I've been testing serf-trunk with subversion-trunk and all seems
> >> fine. There are new features that Subversion doesn't use
> >> (specifically, the OCSP stuff for validating certificates -- but,
> >> AFAIK, that's still live somewhere else). Whether or not they pick
> >> this up is really not a question we have to solve before releasing.
> >
> > I take that back. I just tried a checkout of the Subversion repo
> with
> > serf-trunk via HTTPS. Crashes in SSL_CTX_new(), with OpenSSL 3.5.0,
> > works fine over HTTP. This is not cool. I hope I didn't introduce a
> > fine bug with some of my recent changes.
> >
> > Ah well. This all goes towards stabilising trunk.
> >
> > -- Brane
> >
>
Re: Releasing 1.4
Posted by Daniel Sahlberg <da...@gmail.com>.
Hi,
Have you started looking at using the new APIs? Any chance you can share
the code?
Cheers,
Daniel
Den mån 30 juni 2025 kl 23:36 skrev Peter Balogh <pe...@svnplus.com>:
> Hi,
>
> If it helps, I've just downloaded two repos, one over 4GB without issue,
> both https, windows debug build, serf user-defined-authn branch
> Also can I hope to get user-defined-authn in the next release? :)
> It's working fine so far for my purposes
>
> Best regards,
> Peter
>
> On 2025. 06. 29. 21:03, Branko Čibej wrote:
> > On 29. 6. 25 09:41, Branko Čibej wrote:
> >> On 27. 6. 25 11:42, Daniel Sahlberg wrote:
> >>> Hi,
> >>>
> >>> I'm very happy to see the rekindled interest in Serf development and
> >>> the
> >>> recent work by Brane on the user-defined-authn branch and by Graham
> >>> on the
> >>> OpenSSL "certificate by URI" PR. I'm planning on reviewing those things
> >>> during the weekend. When these are merged (and it doesn't only
> >>> depend on
> >>> me, it is of course a team effort reviewing and merging!) we should
> >>> start
> >>> thinking about a new release.
> >>>
> >>> I don't think it makes sense to backport to 1.3 - they would add new
> >>> APIs
> >>> that require a version bump.
> >>>
> >>> The existing 1.4.x branch was created in 2018 and received a few
> >>> backports
> >>> the same year but it lacks significant work from trunk, for example
> >>> Evgeny's OpenSSL3 work in 2022 that led up to the release of 1.3.10.
> >>>
> >>> I'm proposing to drop the current 1.4.x branch and create a new one
> >>> based
> >>> on trunk. Alternative option to drop 1.4.x completely and instead
> >>> name the
> >>> new release 1.5.
> >>
> >> I'm inclined towards calling the next release 1.5 and retiring 1.4.x.
> >> There are so many changes on trunk that have not been backported that
> >> it would amount to the same thing -- a wholesale merge from trunk.
> >> Gathering all the backport proposals into STATUS and then voting on
> >> each one would take longer than validating that trunk is stable.
> >>
> >> I've been testing serf-trunk with subversion-trunk and all seems
> >> fine. There are new features that Subversion doesn't use
> >> (specifically, the OCSP stuff for validating certificates -- but,
> >> AFAIK, that's still live somewhere else). Whether or not they pick
> >> this up is really not a question we have to solve before releasing.
> >
> > I take that back. I just tried a checkout of the Subversion repo with
> > serf-trunk via HTTPS. Crashes in SSL_CTX_new(), with OpenSSL 3.5.0,
> > works fine over HTTP. This is not cool. I hope I didn't introduce a
> > fine bug with some of my recent changes.
> >
> > Ah well. This all goes towards stabilising trunk.
> >
> > -- Brane
> >
>
Re: Releasing 1.4
Posted by Peter Balogh <pe...@svnplus.com>.
Hi,
If it helps, I've just downloaded two repos, one over 4GB without issue,
both https, windows debug build, serf user-defined-authn branch
Also can I hope to get user-defined-authn in the next release? :)
It's working fine so far for my purposes
Best regards,
Peter
On 2025. 06. 29. 21:03, Branko Čibej wrote:
> On 29. 6. 25 09:41, Branko Čibej wrote:
>> On 27. 6. 25 11:42, Daniel Sahlberg wrote:
>>> Hi,
>>>
>>> I'm very happy to see the rekindled interest in Serf development and
>>> the
>>> recent work by Brane on the user-defined-authn branch and by Graham
>>> on the
>>> OpenSSL "certificate by URI" PR. I'm planning on reviewing those things
>>> during the weekend. When these are merged (and it doesn't only
>>> depend on
>>> me, it is of course a team effort reviewing and merging!) we should
>>> start
>>> thinking about a new release.
>>>
>>> I don't think it makes sense to backport to 1.3 - they would add new
>>> APIs
>>> that require a version bump.
>>>
>>> The existing 1.4.x branch was created in 2018 and received a few
>>> backports
>>> the same year but it lacks significant work from trunk, for example
>>> Evgeny's OpenSSL3 work in 2022 that led up to the release of 1.3.10.
>>>
>>> I'm proposing to drop the current 1.4.x branch and create a new one
>>> based
>>> on trunk. Alternative option to drop 1.4.x completely and instead
>>> name the
>>> new release 1.5.
>>
>> I'm inclined towards calling the next release 1.5 and retiring 1.4.x.
>> There are so many changes on trunk that have not been backported that
>> it would amount to the same thing -- a wholesale merge from trunk.
>> Gathering all the backport proposals into STATUS and then voting on
>> each one would take longer than validating that trunk is stable.
>>
>> I've been testing serf-trunk with subversion-trunk and all seems
>> fine. There are new features that Subversion doesn't use
>> (specifically, the OCSP stuff for validating certificates -- but,
>> AFAIK, that's still live somewhere else). Whether or not they pick
>> this up is really not a question we have to solve before releasing.
>
> I take that back. I just tried a checkout of the Subversion repo with
> serf-trunk via HTTPS. Crashes in SSL_CTX_new(), with OpenSSL 3.5.0,
> works fine over HTTP. This is not cool. I hope I didn't introduce a
> fine bug with some of my recent changes.
>
> Ah well. This all goes towards stabilising trunk.
>
> -- Brane
>
Re: Releasing 1.4
Posted by Branko Čibej <br...@apache.org>.
On 29. 6. 25 09:41, Branko Čibej wrote:
> On 27. 6. 25 11:42, Daniel Sahlberg wrote:
>> Hi,
>>
>> I'm very happy to see the rekindled interest in Serf development and the
>> recent work by Brane on the user-defined-authn branch and by Graham
>> on the
>> OpenSSL "certificate by URI" PR. I'm planning on reviewing those things
>> during the weekend. When these are merged (and it doesn't only depend on
>> me, it is of course a team effort reviewing and merging!) we should
>> start
>> thinking about a new release.
>>
>> I don't think it makes sense to backport to 1.3 - they would add new
>> APIs
>> that require a version bump.
>>
>> The existing 1.4.x branch was created in 2018 and received a few
>> backports
>> the same year but it lacks significant work from trunk, for example
>> Evgeny's OpenSSL3 work in 2022 that led up to the release of 1.3.10.
>>
>> I'm proposing to drop the current 1.4.x branch and create a new one
>> based
>> on trunk. Alternative option to drop 1.4.x completely and instead
>> name the
>> new release 1.5.
>
> I'm inclined towards calling the next release 1.5 and retiring 1.4.x.
> There are so many changes on trunk that have not been backported that
> it would amount to the same thing -- a wholesale merge from trunk.
> Gathering all the backport proposals into STATUS and then voting on
> each one would take longer than validating that trunk is stable.
>
> I've been testing serf-trunk with subversion-trunk and all seems fine.
> There are new features that Subversion doesn't use (specifically, the
> OCSP stuff for validating certificates -- but, AFAIK, that's still
> live somewhere else). Whether or not they pick this up is really not a
> question we have to solve before releasing.
I take that back. I just tried a checkout of the Subversion repo with
serf-trunk via HTTPS. Crashes in SSL_CTX_new(), with OpenSSL 3.5.0,
works fine over HTTP. This is not cool. I hope I didn't introduce a fine
bug with some of my recent changes.
Ah well. This all goes towards stabilising trunk.
-- Brane
Re: Releasing 1.4
Posted by Greg Stein <gs...@gmail.com>.
I agree with just burning the 1.4.x version. I think it is in a very
confused state, so let's just toss out that version number. They're
cheap/free.
The stuff that I was trying out can also be eliminated. I'll take a look.
It's been a long while. I don't recall if there is enough to move it to a
branch, or just delete entirely. ... In any case, it should not be in a
release.
CMake should remain experimental (IMO). My mind has changed, after Ryan's
feedback. I'll post other-thread on that. CMake might be better
longer-term, despite my leanings.
Cheers,
-g
On Sun, Jun 29, 2025 at 7:09 AM Nathan Hartman <ha...@gmail.com>
wrote:
> On Sun, Jun 29, 2025 at 3:42 AM Branko Čibej <br...@apache.org> wrote:
>
> > On 27. 6. 25 11:42, Daniel Sahlberg wrote:
> > > Hi,
> > >
> > > I'm very happy to see the rekindled interest in Serf development and
> the
> > > recent work by Brane on the user-defined-authn branch and by Graham on
> > the
> > > OpenSSL "certificate by URI" PR. I'm planning on reviewing those things
> > > during the weekend. When these are merged (and it doesn't only depend
> on
> > > me, it is of course a team effort reviewing and merging!) we should
> start
> > > thinking about a new release.
> > >
> > > I don't think it makes sense to backport to 1.3 - they would add new
> APIs
> > > that require a version bump.
> > >
> > > The existing 1.4.x branch was created in 2018 and received a few
> > backports
> > > the same year but it lacks significant work from trunk, for example
> > > Evgeny's OpenSSL3 work in 2022 that led up to the release of 1.3.10.
> > >
> > > I'm proposing to drop the current 1.4.x branch and create a new one
> based
> > > on trunk. Alternative option to drop 1.4.x completely and instead name
> > the
> > > new release 1.5.
> >
> > I'm inclined towards calling the next release 1.5 and retiring 1.4.x.
> > There are so many changes on trunk that have not been backported that it
> > would amount to the same thing -- a wholesale merge from trunk.
> > Gathering all the backport proposals into STATUS and then voting on each
> > one would take longer than validating that trunk is stable.
>
>
> Ditto. Let's just leave the 1.4.x branch as-is and call the next release
> 1.5.
>
> I've been testing serf-trunk with subversion-trunk and all seems fine.
> > There are new features that Subversion doesn't use (specifically, the
> > OCSP stuff for validating certificates -- but, AFAIK, that's still live
> > somewhere else). Whether or not they pick this up is really not a
> > question we have to solve before releasing.
> >
> > We don't have to solve the build system dilemma for 1.5, either. I would
> > keep the "experimental" bit on CMake for this next release, though;
> > there are sure to be things that need ironing out. It would be good to
> > get some feedback on this from someone who has to package Serf on a
> > regular basis.
>
>
> +1
>
>
> >
> > -- Brane
> >
> Cheers
> Nathan
>
Re: Releasing 1.4
Posted by Nathan Hartman <ha...@gmail.com>.
On Sun, Jun 29, 2025 at 3:42 AM Branko Čibej <br...@apache.org> wrote:
> On 27. 6. 25 11:42, Daniel Sahlberg wrote:
> > Hi,
> >
> > I'm very happy to see the rekindled interest in Serf development and the
> > recent work by Brane on the user-defined-authn branch and by Graham on
> the
> > OpenSSL "certificate by URI" PR. I'm planning on reviewing those things
> > during the weekend. When these are merged (and it doesn't only depend on
> > me, it is of course a team effort reviewing and merging!) we should start
> > thinking about a new release.
> >
> > I don't think it makes sense to backport to 1.3 - they would add new APIs
> > that require a version bump.
> >
> > The existing 1.4.x branch was created in 2018 and received a few
> backports
> > the same year but it lacks significant work from trunk, for example
> > Evgeny's OpenSSL3 work in 2022 that led up to the release of 1.3.10.
> >
> > I'm proposing to drop the current 1.4.x branch and create a new one based
> > on trunk. Alternative option to drop 1.4.x completely and instead name
> the
> > new release 1.5.
>
> I'm inclined towards calling the next release 1.5 and retiring 1.4.x.
> There are so many changes on trunk that have not been backported that it
> would amount to the same thing -- a wholesale merge from trunk.
> Gathering all the backport proposals into STATUS and then voting on each
> one would take longer than validating that trunk is stable.
Ditto. Let's just leave the 1.4.x branch as-is and call the next release
1.5.
I've been testing serf-trunk with subversion-trunk and all seems fine.
> There are new features that Subversion doesn't use (specifically, the
> OCSP stuff for validating certificates -- but, AFAIK, that's still live
> somewhere else). Whether or not they pick this up is really not a
> question we have to solve before releasing.
>
> We don't have to solve the build system dilemma for 1.5, either. I would
> keep the "experimental" bit on CMake for this next release, though;
> there are sure to be things that need ironing out. It would be good to
> get some feedback on this from someone who has to package Serf on a
> regular basis.
+1
>
> -- Brane
>
Cheers
Nathan
Re: Releasing 1.4
Posted by Branko Čibej <br...@apache.org>.
On 27. 6. 25 11:42, Daniel Sahlberg wrote:
> Hi,
>
> I'm very happy to see the rekindled interest in Serf development and the
> recent work by Brane on the user-defined-authn branch and by Graham on the
> OpenSSL "certificate by URI" PR. I'm planning on reviewing those things
> during the weekend. When these are merged (and it doesn't only depend on
> me, it is of course a team effort reviewing and merging!) we should start
> thinking about a new release.
>
> I don't think it makes sense to backport to 1.3 - they would add new APIs
> that require a version bump.
>
> The existing 1.4.x branch was created in 2018 and received a few backports
> the same year but it lacks significant work from trunk, for example
> Evgeny's OpenSSL3 work in 2022 that led up to the release of 1.3.10.
>
> I'm proposing to drop the current 1.4.x branch and create a new one based
> on trunk. Alternative option to drop 1.4.x completely and instead name the
> new release 1.5.
I'm inclined towards calling the next release 1.5 and retiring 1.4.x.
There are so many changes on trunk that have not been backported that it
would amount to the same thing -- a wholesale merge from trunk.
Gathering all the backport proposals into STATUS and then voting on each
one would take longer than validating that trunk is stable.
I've been testing serf-trunk with subversion-trunk and all seems fine.
There are new features that Subversion doesn't use (specifically, the
OCSP stuff for validating certificates -- but, AFAIK, that's still live
somewhere else). Whether or not they pick this up is really not a
question we have to solve before releasing.
We don't have to solve the build system dilemma for 1.5, either. I would
keep the "experimental" bit on CMake for this next release, though;
there are sure to be things that need ironing out. It would be good to
get some feedback on this from someone who has to package Serf on a
regular basis.
-- Brane
Re: Releasing 1.4
Posted by Branko Čibej <br...@apache.org>.
On 2. 7. 25 18:42, Graham Leggett wrote:
> On 02 Jul 2025, at 17:16, Ivan Zhakov<iv...@apache.org> wrote:
>
>> With these points in mind, merging Serf into Subversion could be a logical
>> step. It would simplify new feature development, allowing more focus on
>> features and less on API and build dependencies.
> I'm not so sure - at the end of all this effort, all you end up with is the same code in a different place. I'm not seeing that as a huge benefit.
>
> I think the fact that serf exists and can be used by people independently of subversion is far more valuable in the long term. I wish more people would use async libraries.
I know for a fact that Serf is used elsewhere, in proprietary contexts
that no research of public sources will tell you about. Precisely
because it's asynchronous.
>> 2. Some popular package managers like Homebrew don't even offer libserf as
>> a separate package, also indicating its lack of independent adoption.
Homebrew is not a "some popuar package managers", it's in fact the only
one I know about that doesn't provide a standalone libserf. MacPorts
does, as do all Linuxes and "the" three *BSDs. Even Haiku has serf
packaged separately.
And even if this were true, I agree with Graham.
>> 3. While I appreciate Serf's internal design and implementation, I think
>> there are no compelling reasons to choose it for a new project over
>> alternatives like libcurl.
So why doesn't Subversion have a libsvn_ra_curl?
"While I appreciate Subversions's internal design and
implementation, I think there are no compelling reasons to choose it
for a new project over alternatives like git."
By your argument, Subversion should just go to the Attic since most
people these days use git. Wasting time on new features, let alone new
releases, is not economical.
>> 4. Subversion is already developing new features that rely on unreleased
>> Serf APIs and capabilities.
Well, that's just misleading. Graham is right at this time preparing
patches for Subversion to use (a) feature(s) that he is, at the same
time, adding to Serf. Generalising from a single data point is not a
valid argument.
>> 5. Almost all Serf committers are also Subversion committers.
This is not an accident, it's intentional.
>> This means that the actual development community is shared, rather than
>> diverse.
Yes, and? Why is that a bad thing, for Serf specifically?
>> 6. Merging Serf into Subversion would eliminate the need to reinvent
>> various patterns in Serf, such as svn_error_t.
>> This could allow reusing existing common primitives within Subversion.
Subversion's and Serfs internal architectures are completely different.
Subversion is streamy, Serf is asynchronous. It's not all that obvious
that there'd be much overlap. Using svn_error_t within Serf isn't such a
boon as you might think, as it's not designed for the kind of error
reporting that Serf needs (arguably "should have but doesn't").
>> With these points in mind, merging Serf into Subversion could be a logical
>> step. It would simplify new feature development, allowing more focus on
>> features and less on API and build dependencies.
I for one see some fallacies in your logic.
You'll have to explain in far more detail why you think that merging the
two projects would "simplify new feature development". Because you'd
have to prepare a single patch instead of two? That wouldn't go away.
The idea of focusing on "features and less on API and build
dependencies" is a bit strange, too. I see that as more of a bad than a
good thing. And which "build dependencies" are we focusing on to the
detriment of everything else?
-- Brane
Re: Releasing 1.4
Posted by Graham Leggett <mi...@sharp.fm.INVALID>.
On 02 Jul 2025, at 17:16, Ivan Zhakov <iv...@apache.org> wrote:
> With these points in mind, merging Serf into Subversion could be a logical
> step. It would simplify new feature development, allowing more focus on
> features and less on API and build dependencies.
I'm not so sure - at the end of all this effort, all you end up with is the same code in a different place. I'm not seeing that as a huge benefit.
I think the fact that serf exists and can be used by people independently of subversion is far more valuable in the long term. I wish more people would use async libraries.
Regards,
Graham
--
Re: Releasing 1.4
Posted by Daniel Sahlberg <da...@gmail.com>.
Den ons 2 juli 2025 kl 18:17 skrev Ivan Zhakov <iv...@apache.org>:
> On Fri, 27 Jun 2025 at 11:43, Daniel Sahlberg <da...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I'm very happy to see the rekindled interest in Serf development and the
>> recent work by Brane on the user-defined-authn branch and by Graham on the
>> OpenSSL "certificate by URI" PR. I'm planning on reviewing those things
>> during the weekend. When these are merged (and it doesn't only depend on
>> me, it is of course a team effort reviewing and merging!) we should start
>> thinking about a new release.
>>
>> I don't think it makes sense to backport to 1.3 - they would add new APIs
>> that require a version bump.
>>
>> The existing 1.4.x branch was created in 2018 and received a few backports
>> the same year but it lacks significant work from trunk, for example
>> Evgeny's OpenSSL3 work in 2022 that led up to the release of 1.3.10.
>>
>> I'm proposing to drop the current 1.4.x branch and create a new one based
>> on trunk. Alternative option to drop 1.4.x completely and instead name the
>> new release 1.5.
>>
>> As far as I understand trunk contains a bunch of HTTP 2-work, but
>> according
>> to Brane earlier on dev@ some is hidden behind #ifdefs that will only
>> expose it if released as Serf 2. Would it make sense to get this released
>> as well? In that case, should we instead aim for Serf 2.0? Alternative
>> option to remove the #ifdefs and declare it stable in Serf 1.
>
>
> I'd like to share an alternative perspective (my two cents) on this topic.
> In short, I believe there are strong, practical reasons to merge Serf
> directly into Subversion:
>
> 1. Based on publicly available information, Subversion is the only actual
> user of Serf.
>
> I checked major Linux distributions (Ubuntu, Debian, CentOS, OpenSUSE) and
> Subversion is consistently the only dependency listed for libserf:
> - Ubuntu:
> https://ubuntu.pkgs.org/25.04/ubuntu-universe-amd64/libserf-1-1_1.3.10-3ubuntu1_amd64.deb.html
> - Debian:
> https://debian.pkgs.org/12/debian-main-amd64/libserf-1-1_1.3.9-11_amd64.deb.html
> - CentOS:
> https://centos.pkgs.org/10-stream/centos-appstream-x86_64/libserf-1.3.10-7.el10.x86_64.rpm.html
> - OpenSUSE:
> https://opensuse.pkgs.org/15.6/opensuse-oss/libserf-1-1-1.3.9-150600.16.2.x86_64.rpm.html
> bilities.
>
> This demonstrates a deep interdependency between the two projects.
>
> 5. Almost all Serf committers are also Subversion committers.
>
> This means that the actual development community is shared, rather
> than diverse.
>
> 6. Merging Serf into Subversion would eliminate the need to reinvent
> various patterns in Serf, such as svn_error_t.
> This could allow reusing existing common primitives within Subversion.
>
> 2. Some popular package managers like Homebrew don't even offer libserf as
> a separate package, also indicating its lack of independent adoption.
>
> 3. While I appreciate Serf's internal design and implementation, I think
> there are no compelling reasons to choose it for a new project over
> alternatives like libcurl.
>
> For example, libcurl offers comprehensive support for:
> - Authentication types (SSPI, CRAM, SASL, OAuth2, Kerberos, etc.)
> - TLS implementations (OpenSSL, Schannel, BearSSL, GnuTLS, Mbed TLS,
> Rustls, wolfSSL)
> - Modern protocols (HTTP/2, HTTP/3)
>
> Serf's primary advantage, which I believe is in how it handles
> asynchronous multiplexing, doesn't appear to be a widely demanded feature
> for most users.
>
> 4. Subversion is already developing new features that rely on unreleased
> Serf APIs and capa
>
> With these points in mind, merging Serf into Subversion could be a logical
> step. It would simplify new feature development, allowing more focus on
> features and less on API and build dependencies.
>
Thanks Ivan for a well formulated e-mail on this topic. I think it is a
question that makes a lot of sense to think about.
I believe it would make sense for Subversion to absorb Serf IF one of these
two conditions are true:
* We have trouble releasing Serf (no problem during the release of 1.3.10).
* If Subversion believe it could simplify the code and/or implement new
features much easier.
The first point is mainly a problem for the Serf community.
The second point might make sense for Subversion with regard to the recent
discussion about error reporting - Subversion could simply kill the
Serf-APIs that doesn't make sense for Subversion. This discussion probably
belong in dev@subversion. Realistically it would probably kill Serf.
I have made the same observation as Ivan regarding open source users of
Serf. Apache OpenOffice used to bundle Serf but switched to Curl about two
years ago. (Last time it was discussed, Greg pulled out some download
statistics[1] (500 downloads per day for the last two months), arguing that
Serf is highly used. However looking at OS (87% on macOS) and Browser (87%
by curl) lead me to believe most if from MacPorts (as a build dep for
Subversion) - for sure we have approx 65 daily downloads that isn't
MacPorts but that is far from widely used). It would really help if the
closed source users could chime in and potentially help making sure Serf
stays healthy in the long term.
Regarding overlap of development community, checking quickly I can only
find Graham and Ivan being committers here and not in Subversion. (In the
PMC, Lieven and Brane are not in Subversion). I don't see a problem with
the overlap nor do I see this as a reason to merge. (Unless we can convince
Ivan to re-join Subversion, but that is probably another discussion ;-) ).
Cheers,
Daniel
[1] https://infra-reports.apache.org/#downloads&project=serf
Re: Releasing 1.4
Posted by Nathan Hartman <ha...@gmail.com>.
On Wed, Jul 2, 2025 at 12:17 PM Ivan Zhakov <iv...@apache.org> wrote:
> On Fri, 27 Jun 2025 at 11:43, Daniel Sahlberg <daniel.l.sahlberg@gmail.com
> >
> wrote:
>
> > Hi,
> >
> > I'm very happy to see the rekindled interest in Serf development and the
> > recent work by Brane on the user-defined-authn branch and by Graham on
> the
> > OpenSSL "certificate by URI" PR. I'm planning on reviewing those things
> > during the weekend. When these are merged (and it doesn't only depend on
> > me, it is of course a team effort reviewing and merging!) we should start
> > thinking about a new release.
> >
> > I don't think it makes sense to backport to 1.3 - they would add new APIs
> > that require a version bump.
> >
> > The existing 1.4.x branch was created in 2018 and received a few
> backports
> > the same year but it lacks significant work from trunk, for example
> > Evgeny's OpenSSL3 work in 2022 that led up to the release of 1.3.10.
> >
> > I'm proposing to drop the current 1.4.x branch and create a new one based
> > on trunk. Alternative option to drop 1.4.x completely and instead name
> the
> > new release 1.5.
> >
> > As far as I understand trunk contains a bunch of HTTP 2-work, but
> according
> > to Brane earlier on dev@ some is hidden behind #ifdefs that will only
> > expose it if released as Serf 2. Would it make sense to get this released
> > as well? In that case, should we instead aim for Serf 2.0? Alternative
> > option to remove the #ifdefs and declare it stable in Serf 1.
>
>
> I'd like to share an alternative perspective (my two cents) on this topic.
> In short, I believe there are strong, practical reasons to merge Serf
> directly into Subversion:
>
> 1. Based on publicly available information, Subversion is the only actual
> user of Serf.
>
> I checked major Linux distributions (Ubuntu, Debian, CentOS, OpenSUSE) and
> Subversion is consistently the only dependency listed for libserf:
> - Ubuntu:
>
> https://ubuntu.pkgs.org/25.04/ubuntu-universe-amd64/libserf-1-1_1.3.10-3ubuntu1_amd64.deb.html
> - Debian:
>
> https://debian.pkgs.org/12/debian-main-amd64/libserf-1-1_1.3.9-11_amd64.deb.html
> - CentOS:
>
> https://centos.pkgs.org/10-stream/centos-appstream-x86_64/libserf-1.3.10-7.el10.x86_64.rpm.html
> - OpenSUSE:
>
> https://opensuse.pkgs.org/15.6/opensuse-oss/libserf-1-1-1.3.9-150600.16.2.x86_64.rpm.html
>
> 2. Some popular package managers like Homebrew don't even offer libserf as
> a separate package, also indicating its lack of independent adoption.
>
> 3. While I appreciate Serf's internal design and implementation, I think
> there are no compelling reasons to choose it for a new project over
> alternatives like libcurl.
>
> For example, libcurl offers comprehensive support for:
> - Authentication types (SSPI, CRAM, SASL, OAuth2, Kerberos, etc.)
> - TLS implementations (OpenSSL, Schannel, BearSSL, GnuTLS, Mbed TLS,
> Rustls, wolfSSL)
> - Modern protocols (HTTP/2, HTTP/3)
>
> Serf's primary advantage, which I believe is in how it handles asynchronous
> multiplexing, doesn't appear to be a widely demanded feature for most
> users.
>
> 4. Subversion is already developing new features that rely on unreleased
> Serf APIs and capabilities.
>
> This demonstrates a deep interdependency between the two projects.
>
> 5. Almost all Serf committers are also Subversion committers.
>
> This means that the actual development community is shared, rather than
> diverse.
>
> 6. Merging Serf into Subversion would eliminate the need to reinvent
> various patterns in Serf, such as svn_error_t.
> This could allow reusing existing common primitives within Subversion.
>
>
> With these points in mind, merging Serf into Subversion could be a logical
> step. It would simplify new feature development, allowing more focus on
> features and less on API and build dependencies.
I made a similar suggestion some months ago (to merge the projects), which
included some similar arguments. It was discussed and ultimately it seems
most of the devs who responded were in favor of keeping these two projects
distinct. (I'm replying from my phone so it isn't convenient to search for
the relevant thread(s) in the archives but I can try later if you're
interested.)
Also from Subversion's perspective, a HTTP client library is a bit out of
scope. That was one of the arguments made against my suggestion. Keeping
Serf a separate project leaves Subversion the flexibility to swap it out
for something else in the future, as was done with the switch from Neon to
Serf many eons ago. So for example Subversion might consider a move to Curl
as you touched on. (I might also have mentioned a move to Curl at the time,
as an alternative to merging the projects, though I didn't take time to
analyze how much work that would require).
Anyway, back here at Serf we have added new PMC members / committers, there
is renewed interest and development here, and it looks like there will be a
release in the near future, after some issues are sorted out, so between
these positive developments and the input received back when I suggested to
merge the projects, I'm satisfied to keep the projects separate for the
time being.
One suggestion I would make is to try to describe Serf's advantages (such
as the asynchronous aspect) a bit better on the serf.a.o website. I know
it's the first bulletpoint but someone who comes across the site may not
realize how significant that bulletpoint potentially is for their project.
I can try to help with this, provided the other devs will be patient when I
ask some potentially dumb questions. :-)
Thanks for providing your thoughts. It's always good to consider
alternative ideas (even if it looks like there isn't much support for this
one in particular).
Thanks,
Nathan
Re: Releasing 1.4
Posted by Ivan Zhakov <iv...@apache.org>.
On Fri, 27 Jun 2025 at 11:43, Daniel Sahlberg <da...@gmail.com>
wrote:
> Hi,
>
> I'm very happy to see the rekindled interest in Serf development and the
> recent work by Brane on the user-defined-authn branch and by Graham on the
> OpenSSL "certificate by URI" PR. I'm planning on reviewing those things
> during the weekend. When these are merged (and it doesn't only depend on
> me, it is of course a team effort reviewing and merging!) we should start
> thinking about a new release.
>
> I don't think it makes sense to backport to 1.3 - they would add new APIs
> that require a version bump.
>
> The existing 1.4.x branch was created in 2018 and received a few backports
> the same year but it lacks significant work from trunk, for example
> Evgeny's OpenSSL3 work in 2022 that led up to the release of 1.3.10.
>
> I'm proposing to drop the current 1.4.x branch and create a new one based
> on trunk. Alternative option to drop 1.4.x completely and instead name the
> new release 1.5.
>
> As far as I understand trunk contains a bunch of HTTP 2-work, but according
> to Brane earlier on dev@ some is hidden behind #ifdefs that will only
> expose it if released as Serf 2. Would it make sense to get this released
> as well? In that case, should we instead aim for Serf 2.0? Alternative
> option to remove the #ifdefs and declare it stable in Serf 1.
I'd like to share an alternative perspective (my two cents) on this topic.
In short, I believe there are strong, practical reasons to merge Serf
directly into Subversion:
1. Based on publicly available information, Subversion is the only actual
user of Serf.
I checked major Linux distributions (Ubuntu, Debian, CentOS, OpenSUSE) and
Subversion is consistently the only dependency listed for libserf:
- Ubuntu:
https://ubuntu.pkgs.org/25.04/ubuntu-universe-amd64/libserf-1-1_1.3.10-3ubuntu1_amd64.deb.html
- Debian:
https://debian.pkgs.org/12/debian-main-amd64/libserf-1-1_1.3.9-11_amd64.deb.html
- CentOS:
https://centos.pkgs.org/10-stream/centos-appstream-x86_64/libserf-1.3.10-7.el10.x86_64.rpm.html
- OpenSUSE:
https://opensuse.pkgs.org/15.6/opensuse-oss/libserf-1-1-1.3.9-150600.16.2.x86_64.rpm.html
2. Some popular package managers like Homebrew don't even offer libserf as
a separate package, also indicating its lack of independent adoption.
3. While I appreciate Serf's internal design and implementation, I think
there are no compelling reasons to choose it for a new project over
alternatives like libcurl.
For example, libcurl offers comprehensive support for:
- Authentication types (SSPI, CRAM, SASL, OAuth2, Kerberos, etc.)
- TLS implementations (OpenSSL, Schannel, BearSSL, GnuTLS, Mbed TLS,
Rustls, wolfSSL)
- Modern protocols (HTTP/2, HTTP/3)
Serf's primary advantage, which I believe is in how it handles asynchronous
multiplexing, doesn't appear to be a widely demanded feature for most users.
4. Subversion is already developing new features that rely on unreleased
Serf APIs and capabilities.
This demonstrates a deep interdependency between the two projects.
5. Almost all Serf committers are also Subversion committers.
This means that the actual development community is shared, rather than
diverse.
6. Merging Serf into Subversion would eliminate the need to reinvent
various patterns in Serf, such as svn_error_t.
This could allow reusing existing common primitives within Subversion.
With these points in mind, merging Serf into Subversion could be a logical
step. It would simplify new feature development, allowing more focus on
features and less on API and build dependencies.
--
Ivan Zhakov