[ Changing the Subject line because this thread has drifted to a different
topic. ]
On Thu, May 31, 2012 at 02:44:32PM -0500, Les Mikesell wrote:
> On Thu, May 31, 2012 at 2:12 PM, Ryan Schmidt
> <subversion-2012a_at_ryandesign.com> wrote:
> >
> >>
> >> Yes, it doesn't seem that bad today. I'm just pointing out that there
> >> will very likely be a large user base continuing to run some version
> >> of 1.6.x for 5 to 10 years in the future.
> >
> > That's fine, if you don't mind running old software its developers will not support anymore. Subversion 1.6.x will become unsupported when Subversion 1.8.0 is released.
>
> But, that puts it at odds with running it on a stable Linux distribution...
So what is different with any other software that these distributions
install. httpd? linux? gcc? firefox? The list is too long too enumerate.
These projects all have the same problem. Some have long-term-support
releases which cater towards downstream consumers such as CentOS.
Are you saying you think it would be a good idea for Subversion to
have a long-term-support release as well (supported for a fixed amount
of time, say, 5 years)?
> >That doesn't mean it will stop working, but it does mean if you report a problem against it at that time, we'll just tell you to upgrade to a supported version first.
>
> Which means you'll now have a one-of-a-kind combination of libraries
> and OS on your system. We all do that when we are forced to - and
> probably most of us have wasted a lot of time tracking down the quirks
> of mismatches between apache modules, openssl components, and other
> libraries. It just seems like an unnecessarily difficult way to get a
> bugfix. There are, of course, 3rd party package repositories that
> will likely have current versions built as installable rpms, but
> packages that replace parts of the base distribution have their own
> issues.
Anyone can maintain a custom release that includes backports that aren't
in the official release. We even provide some documentation on how to do
this: http://subversion.apache.org/docs/community-guide/releasing.html#custom-releases
However, it would make more sense to support the community in this regard,
rather than maintaining a custom release.
You're obviously seeing a problem the community has so far failed to deliver
a solution for. One way of fixing this is to work with the community to
create the solution. If you feel that maintaining a long-term-support release
variant of Subversion is worth your time and effort, I doubt there would be
many roadblocks on the way of making this a reality. Provided that you or
someone else put in the necessary work.
Received on 2012-05-31 22:02:37 CEST