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

Re: [PATCH] Have svn require Neon 0.19.3

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-02-26 03:36:31 CET

On Mon, Feb 25, 2002 at 08:50:45PM -0500, Daniel Berlin wrote:
> On Mon, 25 Feb 2002, Garrett Rooney wrote:
> > On Mon, Feb 25, 2002 at 08:14:44PM -0500, Ben Collins wrote:
> > > Is there anyway we can not force a specific version of neon for the
> > > builds, and maybe use a range of versions that work? 0.19.2 is perfectly
> > > fine to use for subversion. It may itself fail to build on win32, but
> > > that doesn't mean that subversion should be restricted 0.19.3.
> >
> > I would also like to see this.
> Can't we just autoconf on NEON_VERSION_MAJOR and NEON_VERSION_MINOR, at
> the very least?
> I would assume they at least bump the minor when the api changes.
> (currently MAJOR == 0, MINOR == 19)

We would need all three: major, minor, and patch. API changes occur even
between patches, so we will sometimes need to specify a specific patch

Also, note that we cannot specify a "minimum". It has to be a bounded
constraint because the revisions are not API compatible moving forward.
Today, we say 0.19.2 and that is all we are guaranteed to run on. 0.19.4
could introduce an API change that breaks us, similar to moving back to
0.19.0 or something.

The net result is that we stick to a specific Neon release. If we specify a
bounded range, then we could tweak the upper bound as new releases come out,
but that upper-bound tweak has to be done manually. For example, today, we
could set the bounds at (0, 19, 2) and (0, 19, 3). Let's say 0.19.4 comes
out; if it works, then we could change the upper bound; but we can't do that
before the release.


Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:09 2006

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.