Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of ben@reser.org designates
 50.197.89.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <51ACA6B1.2010907@collab.net>
References: <51ACA6B1.2010907@collab.net>
Date: Mon, 3 Jun 2013 08:31:24 -0700
Message-ID: 
 <CADkdwvR9kUOepOe1-5YQVsKPjaoe9Bc3_pAcA9tYRnvoixNEUw@mail.gmail.com>
Subject: Re: [serf-dev] Serf issue #102 and 1.8.0 release timing
From: Ben Reser <ben@reser.org>
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 7:22 AM, C. Michael Pilato <cmpilato@collab.net> wrote:
> 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,
> we're at least release_date(serf_1.2.1) + 28 days away from 1.8.0-final
> again.  If they are not, then we should hold off on 1.8.0-rc3 until Serf
> 1.2.1 is produced (hopefully Real Soon Now), and then our final release can
> come a week after that.

My vote is to not restart the soak.  The plan to wait to produce
1.8.0-rc3 until serf 1.2.1 is available and adjust the dependency
requirements is exactly what I was planning to do.

Given that there's a great deal of overlap in developers with Serf and
Subversion, I trust that the Serf folks can choose appropriate changes
for 1.2.1 that won't be destabilizing.