Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of gstein@gmail.com designates
 209.85.212.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <51ACA6B1.2010907@collab.net>
References: <51ACA6B1.2010907@collab.net>
Date: Mon, 3 Jun 2013 14:58:56 -0400
Message-ID: 
 <CABD8fLWfn2Yd_0m9NXnUoLAgZY_FeA1ZuD=LDMpqXGrzLeP9fA@mail.gmail.com>
Subject: Re: [serf-dev] Serf issue #102 and 1.8.0 release timing
From: Greg Stein <gstein@gmail.com>
To: serf-dev@googlegroups.com
Cc: Subversion Development <dev@subversion.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jun 3, 2013 at 10:22 AM, C. Michael Pilato <cmpilato@collab.net> wrote:
>...
> On the other hand, Serf 1.2.0 is the only available public Serf release with
> which Subversion 1.8.0 can operate[2], which really rather limits folks'
>...
> Unfortunately, there is as yet no public Serf release to date which contains
> the fix for this problem.

Released. 1.2.1 is up on Google Code, and messages sent out.

>...
> I'll suggest that the answer is found in how we'd track the issue locally.
> "Subversion requires Serf 1.2.1" would be a reasonable issue description.
> It would naturally be a 1.8.0 blocking issue.  It's resolution (on our end,
> at least) would be simple -- some build system twiddling is all.  What
> remains, then, is the determination of whether those changes (and it is
> arguably fair to consider all the changes made between Serf 1.2.0 and 1.2.1,
> here, too) are destabilizing or not.  If they are considered destabilizing,

Nah. They're fine.

But I'll go one step further: you shouldn't care at all.

I could release 1.2.2 tomorrow with all kinds of crap. Or maybe the
day after 1.8.0 goes final. Not much you can do about it. Subversion
needs to soak its own code, not the entire dependency stack.

Cheers,
-g