Steve Cohen wrote:
>>[...] But still, what features
>>above what the current version of these packages support does Subversion
>>need? Being conservative in what features you'll be using from
>>dependency packages will increase subversion's stability and require
>>less of a bleeding-edge mentality.
Erik Huelsmann wrote:
> Some of the dependencies listed are dependencies of dependencies: Apache and
> Neon can build against libz, Neon builds against libxml or expat. We can't
> really make any promises about which version will be the minimum for any
> period time for the deps of deps.
I don't think that is right. For example, if we require Apache >= 2.0.49, and
Apache 2.0.49 requires libz >= 99, then the minimum version of libz that we
require is 99. If a user has a later version of Apache that needs a later
version of libz then obviously they will have a later version of libz, but we
didn't require that.
Actually we shouldn't try to specify deps of deps authoritatively; we should
just say something like, "For your convenience, here are what we believe to be
the minimum dependencies of some of the packages we depend on: ..."
> Also, since we built on non-1.0 software (or at least development software
> as in case of SWIG 1.3), we can't guarantee we won't require a new version
> next 1.x release: for example Neon will have some crucial fixes in its 0.25
> release we need to provide better user experience [interruptable checkouts].
This seems to miss Steve's point that we don't always _need_ to provide such
enhancements. In this example, we could provide interruptable checkouts iff
the installed version of Neon supports it, and _recommend_ such a version of
Neon in order to provide a better user experience, but not _require_ it.
Of course that is more work for us, so we have to decide for each such case
whether it is worth the effort, but it's a valid argument that we should
consider keeping our requirements low in order to make installation easier.
This applies more and more as the project matures and the number of users
> In case of Neon, a new feature will have major usability consequences (for the
> better). I think *not* adopting such new versions costs us users too.
That depends on whether the use of the new version is mandatory or optional.
Maybe our dependencies are already conservative enough for most people - I
don't know. Certainly we need to keep this in mind.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Feb 16 12:28:34 2005