> >>i.e. "Subversion supports the following platforms Windows 2K, XP,
> >>solaris xxx, RedHat Linux > x.x, Debian > x.x. Also required are
> >>Apache > x.x, etc."
> >
> >
> > We don't enumerate all Linux distros, but in the README there is a list
> of
> > all prerequisites:
> >
> > Apache
> > APR
> > Neon
> > Berkely DB
> > libxml / expat
> > libz
> > gettext
> > etc.
> >
> >
>
> This is good. I think you should also list version numbers and stick to
> them. That way users would have more confidence that they won't have to
> replace their OS just to upgrade subversion. Today I've seen RedHat 9.0
> described as EOL. It's less than 2 years old! Granted, I primarily
> blame RedHat itself for this state of affairs. 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.
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.
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].
> > Having a list of minimum requirements by itself does not assure you of
> that.
> > Only the intention to keep them stable will help you there.
>
> Agreed. That's what I'm asking for.
I'm sorry, but we do the best we can. We can't guarantee it. After all, you
want next releases to get better for you too.
> You haven't answered my question. If you can't say, we'll work with any
> apache back to v. x.x.x and plan to keep it that way, you do not enhance
> your reputation for stability.
Well, I think the example was poorly chosen: of any webserver you can run, I
think Apache is the most stable one available (depending on which modules
you load ofcourse).
Apart from that: we try to keep ourselves to patch releases. In case of SWIG
1.3, that does not help as even patch releases are just not compatible. 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.
BTW: Software stability and keeping up with newest version releases might
not be conflicting. Adopting new code of our own too soon and carelessly is
going to have
much more impact.
> > Have a look at the testimonials page to see who's using svn:
> > http://subversion.tigris.org/propaganda.html
>
> I'm sure they are. But simpler installs are a big part of "ready for
> prime time." At this point in time, I would not dream of recommending
> that my employer adopt subversion. It demands a higher caliber of
> developer than those I've seen there. Without a GUI, many of them are
> lost. I hope to be able to recommend subversion there once there is a
> stable subeclipse. You guys are making progress. Keep it up and you'll
> get there.
Well, in my opinion, 'simple installs' should use pre-built binaries. As
soon as you have to build yourself (for whatever reason), you just aren't a
simple install anymore. I'm sorry the summersoft rpms did not work out,
since that obviously is a BFI (Bad First Impression). I'm affraid it doesn't
mean anything about the Subversion software though.
bye,
Erik.
--
DSL Komplett von GMX +++ Supergünstig und stressfrei einsteigen!
AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 16 00:24:54 2005