[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Serf issue #102 and 1.8.0 release timing

From: Greg Stein <gstein_at_gmail.com>
Date: Mon, 3 Jun 2013 13:28:00 -0400

Belay that. I merged a couple extra things in the test suite, and
dropped one (just dealing with fixing a couple compiler warnings).

I'm going to wait for Lieven's +1 before cutting a release.

Cheers,
-g

On Mon, Jun 3, 2013 at 12:53 PM, Greg Stein <gstein_at_gmail.com> wrote:
> Lieven produced a short list of changes to release in 1.2.1, which I'm
> merging now. The release should be done in about an hour.
>
> Cheers,
> -g
>
>
> On Mon, Jun 3, 2013 at 11:36 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> On 06/03/2013 11:18 AM, Branko ÄŒibej wrote:
>>> I think it's clear that we have to wait for a Serf bugfix release before
>>> releasing RC3, and during that time our soak period is simply on hold.
>>> What happens after Serf 1.2.1 is released depends on the changes there.
>>> If it's just a trivial bugfix for the digest authn issue, then we can
>>> simply continue our soak (of which there are, IIRC, another two weeks).
>>> If not -- then we're faced with a significant change in a non-optional
>>> dependency and I can't think we can wiggle our way out of restarting the
>>> soak in that case.
>>
>> FWIW, I am of the same mind. So far, the 1.2.x branch on Serf contains the
>> following changes made since the 1.2.0 release itself:
>>
>> {{{
>> ------------------------------------------------------------------------
>> r1881 | chemodax | 2013-05-31 09:21:20 -0400 (Fri, 31 May 2013) | 2 lines
>>
>> Merge r1880 from trunk: Fix build with old Windows Platform SDK (issue #100)
>>
>> ------------------------------------------------------------------------
>> r1868 | chemodax | 2013-05-21 06:16:59 -0400 (Tue, 21 May 2013) | 7 lines
>>
>> On 1.2.x branch.
>>
>> Merge r1819 from trunk:
>> SPNego authentication optimization.
>> Justification:
>> Avoid lookup through response headers on every read.
>>
>> ------------------------------------------------------------------------
>> r1865 | lieven.govaerts_at_gmail.com | 2013-05-20 10:16:16 -0400 (Mon, 20 May
>> 2013) | 10 lines
>>
>> On the 1.2.x branch:
>> Fix issue in serfmake where serf-1.pc is only created when explicitly invoking
>> 'serfmake build', not when going directly to 'serfmake install'.
>>
>> Applied directly to this branch as serfmake was removed from trunk.
>>
>> Patch by: Gabriela Gibson
>>
>> * serfmake: Add .pc file as build target for the install command.
>>
>> ------------------------------------------------------------------------
>> r1864 | lieven.govaerts_at_gmail.com | 2013-05-20 09:44:26 -0400 (Mon, 20 May
>> 2013) | 8 lines
>>
>> On the 1.2.x branch:
>> Fix issue #95 by applying the patch attached to that issue.
>> Applied directly to this branch as the autoconf build files were removed
>> from trunk.
>>
>> Patch by: Andreas Stieger
>>
>> * configure.in: Add gssapi option to build Kerberos/Negotiate authn module.
>>
>> ------------------------------------------------------------------------
>> r1805 | chemodax | 2013-04-23 12:11:11 -0400 (Tue, 23 Apr 2013) | 2 lines
>>
>> Merge r1804 from trunk: Improve diagnostic of SSPI authentication failures.
>>
>> }}}
>>
>> It's not a great deal of change[1] in terms of code churn, and the fix for
>> issue #102 itself wasn't really all that complicated either. Fortunately,
>> we have the advantage that most of the Serf developership consists of
>> Subversioneers -- so I'll defer the "destabilizing or not" determination to
>> those guys.
>>
>> -- C-Mike
>>
>> [1] svn diff --old http://serf.googlecode.com/svn/tags/1.2.0 \
>> --new http://serf.googlecode.com/svn/branches/1.2.x
>> [2] https://code.google.com/p/serf/source/detail?r=1885
>>
>> --
>> C. Michael Pilato <cmpilato_at_collab.net>
>> CollabNet <> www.collab.net <> Enterprise Cloud Development
>>
Received on 2013-06-03 19:28:33 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.