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 <hartman.nat...@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 >
