You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Hyrum K. Wright" <hy...@mail.utexas.edu> on 2010/03/10 18:34:00 UTC
Bump minimal APR version
I'd like to propose that we bump the minimal APR version from the current 0.9.7 to something a bit more modern, say 1.3.0.
1.3.0 was released in June 2008, and we are already conditionally using parts of it. In fact, in the 1.6.x series, we've even shipped APR/APR-util 1.3.x in the deps tarball. Neither of these practices have caused consternation among our users, who almost exclusively use the system-provided APR (or the one compiled into their client).
We are currently planning on making ra_serf the default dav provider in Subversion 1.7. As ra_serf depends on serf, and the latter requires APR at least 1.x, I think it reasonable that we bump our minimal required APR version as well.
In that past, I recall some pressing reason for still keeping 0.9.7 as the minimal required version, but I don't recall what those arguments were, nor do I think they are still relevant.
Thoughts?
-Hyrum
Re: Bump minimal APR version
Posted by Jack Repenning <ja...@tigris.org>.
On Mar 11, 2010, at 8:03 AM, Mark Phippard wrote:
> How old something is should not be relevant. It should be based on
> what it is costing us to still support it.
While the effort to maintain core Subversion is a factor to consider, it seems to me one of the lesser ones: the most important factor is the impact on the actual users. Packagers (and I'm one!) fall somewhere in between.
In real terms, that would mean that WC format and wire protocol were the most critical forms of compatibility (isn't it odd that they occupy diametrically opposite points in the historical SVN compatibility support spectrum?).
But since this discussion is actually about APR: as a well-documented backwards-compatibility curmudgeon, and frequent complainer about APR versionitis, it may be helpful to note that I upgraded SCPlugin to APR 1.x during the SVN 1.5 release/upgrade cycle (so I could use the deps tarball). Not without ill grace, mind you, but I did.
-==-
Jack Repenning
jackrepenning@tigris.org
Project Owner
SCPlugin
http://scplugin.tigris.org
"Subversion for the rest of OS X"
Re: Bump minimal APR version
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Mar 11, 2010 at 10:48 AM, Jeremy Whitlock <jc...@gmail.com> wrote:
>> I don't get this. We are willing to do things like require Python 2.4
>> (which we did in 1.6) and consider requiring APR 1.3. These sorts of
>> things impact a significant number of our users and really bring us as
>> developers only modest benefits in terms of making our lives easier.
>
> I don't know man. Even Python 2.4 is almost 5 years old already and just "upgrading" it came
> with many things that just made life easier, like subprocess for example. Apache 2.0 is almost
> 11 years old.
How old something is should not be relevant. It should be based on
what it is costing us to still support it. Usually this would only be
an issue if we cannot take advantage of something because of
supporting an older version. The patch to put back Python 2.3 support
is pretty small. I do not see why it was important to us.
> Finally, not only is RHEL4 5 years old but it's reached its EOL.
This is not true. RHEL 3 is even still in support until later this
year. RHEL 4 has simply transitioned to a phase of support where the
criteria for making a fix is higher.
http://www.redhat.com/security/updates/errata/
There are a lot of reasons enterprises run these older versions, and
they are not all that they want to just run older versions. They
could have hardware driver issues they are dealing with or they could
have applications that require the older versions and have not been
updated etc. We should not stop supporting these users unless we have
compelling reasons.
Like I said, compared to the other compatibility hoops we jump through
based on our own rules, supporting these things ought to be minor.
And as Peter pointed out, we are possibly even playing loose with our
own rules when we drop these things.
I just want SVN to be a better product and churning out new releases
quicker. If dropping APR 0.9.x gets us a better product and shortens
development time, go for it. At the same time, I'd be happy to see us
blow up libsvn_wc and tell users to just deal with it for the same
reasons.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Bump minimal APR version
Posted by Jeremy Whitlock <jc...@gmail.com>.
>> My general thoughts on stuff like this is that folks want a newer version of Subversion, they may > need to upgrade their dependencies. If they are unable or unwilling to do so, then they will just
>> have to stick with the older version of Subversion. If these means that somebody on a RHEL 4.0
>> box who is stuck using httpd 2.0.x can't run Subversion 1.7 without more work, tough. I suspect
>> these folks are a relatively small number of our usership.
>
> I don't get this. We are willing to do things like require Python 2.4
> (which we did in 1.6) and consider requiring APR 1.3. These sorts of
> things impact a significant number of our users and really bring us as
> developers only modest benefits in terms of making our lives easier.
I don't know man. Even Python 2.4 is almost 5 years old already and just "upgrading" it came with many things that just made life easier, like subprocess for example. Apache 2.0 is almost 11 years old. Finally, not only is RHEL4 5 years old but it's reached its EOL. As maintainer of one of the more complete binaries for OS X, I know how difficult it is to support such old dependencies and libraries, let alone find environment old enough to even build on those older environments. That being said, I've already dropped Tiger support from my binary, which was using Python 2.3/APR 0.9.x/httpd 2.0.x, and I've had no push back at all from any users at this point. Just something to think about.
Jeremy Whitlock <jc...@gmail.com>
http://www.thoughtspark.org
Re: Bump minimal APR version
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Mar 12, 2010, at 12:13 AM, Greg Stein wrote:
> On Thu, Mar 11, 2010 at 22:44, Hyrum K. Wright
> <hy...@mail.utexas.edu> wrote:
>
>> ...
>>> I believe the above statements about our compatibility guidelines are
>>> orthogonal to supporting APR 0.9.x. It's a fair discussion to have,
>>> but I believe it is a very separate and long discussion. I think if we
>>> want to break any level of compat, then we move to 2.0, strip the
>>> cruft, and restart with the *same* compat restrictions. If the step to
>>> 2.0 is simply dropping deprecated stuff, then most users won't have a
>>> problem with it; only tools using our API/ABI will need to perform
>>> some work. Not sure what other changes would cause a step to 2.0,
>>> beyond a simple desire to "rm libsvn_*/deprecated.c"
>>
>> I don't know that there will be some landmark event. At some point, the cost of carrying around the backward compat gets overly burdensome, and it just makes sense to loosen the restrictions, bump to 2.0, and clean everything up. Witness the amount of cleanup that has been doable in the JavaHL bindings since we repackaged and effectively gained the chance to break API compat. Such a change can be accomplished with grace (see Python 3), and is as much a communication problem as a technical one.
>
> Hmm? I thought we are *maintaining* compat under the
> org.tigris.subversion objects, and doing all the conceptual cleanup
> under org.apache. Did I miss something?
We are maintaining compat with the org.tigris namespace. The benefit, though, is that the org.apache namespace is completely new, so in those packages we can drop all the deprecated classes/interfaces/methods.
>> Regarding the discussion about our compatibility guidelines, that might be a good point to add to the agenda for the NYC discussions in a couple of weeks. :)
>
> Heh. Talk your jaw off. I designed those guidelines 10 years ago. I
> think they have done a great service for our community, and I'm going
> to be *very* curmudgeonly about any changes around the policy. :-)
> Personally, I see no reason to leave them behind if/when we ever bump
> to 2.0. Those guidelines *do* describe what a bump to 2.0 means.
I do not doubt your curmudgeonliness, but I'm not talking about revamping the guidelines. Really, I think it would be useful to talk about the application thereof, not changing the policy.
-Hyrum
Re: Bump minimal APR version
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Mar 11, 2010 at 22:44, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
>...
>> Strawman answer? Just don't provide packages for Apache; just the
>> client. Okay, great. The admin updates the client packages, which
>> includes libsvn_subr-1.so, which NOW links against libapr-1.so. The
>> 2.0 httpd on that box gets restarted at some point, and loads
>> libapr-0.so, and then loads libsvn_subr-1.so which loads libapr-1.so.
>> OOPS. Or maybe that subr tries to work against libapr-0, finding the
>> symbols already in the address space.
>>
>> Net result: admins no longer have a "safe update" policy. I think that
>> is a big mistake.
>
> While I agree that this has been, and will continue to be a good policy, someday we will create a release which breaks it. We can call it 2.0, but one day it's gonna happen. :)
Agreed. And yes, we will call it 2.0 because that tells our community
"there are various kinds of breakage here; read for more details".
>...
>> I believe the above statements about our compatibility guidelines are
>> orthogonal to supporting APR 0.9.x. It's a fair discussion to have,
>> but I believe it is a very separate and long discussion. I think if we
>> want to break any level of compat, then we move to 2.0, strip the
>> cruft, and restart with the *same* compat restrictions. If the step to
>> 2.0 is simply dropping deprecated stuff, then most users won't have a
>> problem with it; only tools using our API/ABI will need to perform
>> some work. Not sure what other changes would cause a step to 2.0,
>> beyond a simple desire to "rm libsvn_*/deprecated.c"
>
> I don't know that there will be some landmark event. At some point, the cost of carrying around the backward compat gets overly burdensome, and it just makes sense to loosen the restrictions, bump to 2.0, and clean everything up. Witness the amount of cleanup that has been doable in the JavaHL bindings since we repackaged and effectively gained the chance to break API compat. Such a change can be accomplished with grace (see Python 3), and is as much a communication problem as a technical one.
Hmm? I thought we are *maintaining* compat under the
org.tigris.subversion objects, and doing all the conceptual cleanup
under org.apache. Did I miss something?
> As for APR, if we're not going to update the deps now, I say we don't even worry about doing it until apr 2.0 ships, and then update for that platform instead. (And as far as I know, that's still a long ways out.)
Yes, and yes.
> Regarding the discussion about our compatibility guidelines, that might be a good point to add to the agenda for the NYC discussions in a couple of weeks. :)
Heh. Talk your jaw off. I designed those guidelines 10 years ago. I
think they have done a great service for our community, and I'm going
to be *very* curmudgeonly about any changes around the policy. :-)
Personally, I see no reason to leave them behind if/when we ever bump
to 2.0. Those guidelines *do* describe what a bump to 2.0 means.
Cheers,
-g
Re: Bump minimal APR version
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Mar 11, 2010, at 3:57 PM, Greg Stein wrote:
> On Thu, Mar 11, 2010 at 11:18, Hyrum K. Wright
> <hy...@mail.utexas.edu> wrote:
>> On Mar 11, 2010, at 9:31 AM, Mark Phippard wrote:
>>> On Thu, Mar 11, 2010 at 10:25 AM, Hyrum K. Wright
>>> <hy...@mail.utexas.edu> wrote:
>>>> My general thoughts on stuff like this is that folks want a newer version of Subversion, they may > need to upgrade their dependencies. If they are unable or unwilling to do so, then they will just
>>>> have to stick with the older version of Subversion. If these means that somebody on a RHEL 4.0
>>>> box who is stuck using httpd 2.0.x can't run Subversion 1.7 without more work, tough. I suspect
>>>> these folks are a relatively small number of our usership.
>>>
>>> I don't get this. We are willing to do things like require Python 2.4
>>> (which we did in 1.6) and consider requiring APR 1.3. These sorts of
>>> things impact a significant number of our users and really bring us as
>>> developers only modest benefits in terms of making our lives easier.
>>
>> I dunno. The *vast* majority of people get a prepackaged client. As Peter mentioned elsewhere, Debian has been shipping apr 1.2.x with Subversion for some time, and I suspect that a large number of other clients have already moved to apr 1.x. The *only* people an apr version bump affects are developers and people who build Subversion from source, who are vastly in the minority. (I'd be interested to know who in the dev community still uses apr 0.9.x, for instance.)
>
> Our longstanding policy has been "hey, feel free to upgrade svn at any
> time. going from 1.x to a later version will never cause a problem."
> We chose this policy so that an admin would KNOW that nothing on the
> system would break if he updated the packages. No tools. No GUI
> clients. No repositories. No working copies. No nothing.
>
> The thing about a prepackaged client is a red herring. By removing
> compat for 0.9.x, then httpd 2.0.x users will be shut out of 1.7 and
> later. Completely. There will never be source or binaries that work in
> that environment.
To be fair, 1.7 clients would still be able to interoperate with httpd 2.0.x servers, but I understand your point.
> Strawman answer? Just don't provide packages for Apache; just the
> client. Okay, great. The admin updates the client packages, which
> includes libsvn_subr-1.so, which NOW links against libapr-1.so. The
> 2.0 httpd on that box gets restarted at some point, and loads
> libapr-0.so, and then loads libsvn_subr-1.so which loads libapr-1.so.
> OOPS. Or maybe that subr tries to work against libapr-0, finding the
> symbols already in the address space.
>
> Net result: admins no longer have a "safe update" policy. I think that
> is a big mistake.
While I agree that this has been, and will continue to be a good policy, someday we will create a release which breaks it. We can call it 2.0, but one day it's gonna happen. :)
>>> Yet, we force ourselves to jump through hoops keeping our libsvn_wc
>>> API compatible, probably tripling the amount of time it takes to
>>> rewrite it. When the impact on our users if we just said screw it and
>>> broke the compatibility would probably be minimal. After all, the API
>>> sucks how many people wrote custom tools to this level of the API as
>>> opposed to libsvn_client? And most of those users would probably live
>>> with the notion that at least their own code would get easier when
>>> they had to update it for a new library.
>>>
>>> Anyway, I know we are not going to change this approach, I just think
>>> we are our own worst enemy some times.
>>
>> I *think* what you're saying is that our compatibility guidelines are a bit screwy. If that's your assertion, I tend to agree. :)
>
> No. He's saying if you're willing throw out one measure of
> compatibility, why not the one causing us so much pain right now? (the
> wc API)
>
>> When we talk about backward compat, there are actually several dimensions we've lumped into one:
>> * API compatibility
>> * ABI compatibility
>> * on-the-wire protocol compatibility
>> * persistent storage formats (wc metadata and repos formats)
>> * command line output (for scripting purposes, etc.)
>>
>> For a long time, we've tried very hard to keep *all* of these backward compatible, but experience has shown that most users only care about a subset of these dimensions (though that subset may differ between groups of users). As Subversion continues to evolve, we need to figure out which areas are important, and which we can drop if/when we go to 2.0.
>>
>> For instance, I believe that we should maintain wire protocol compat ad infinitum, even through 2.0, simply because it allows people to continue deploy a heterogeneous client/server environment. We've already practically broken our wc metadata format, and we've occasionally extended the command line output when it's made sense. (I often wonder how people who scripted against 'svn up' dealt with the new conflict summary.)
>>
>> Staying backward ABI compatible *forever* just isn't scalable. At some point, the costs outweigh the benefits , and I'm suggesting that maybe we should start thinking about what the costs are, and whether it makes sense to tell the 0.0001% of people who'd need to recompile to do so. (This is somewhat analogous to the decision to not upgrade pending logs in wc-ng.)
>
> I believe the above statements about our compatibility guidelines are
> orthogonal to supporting APR 0.9.x. It's a fair discussion to have,
> but I believe it is a very separate and long discussion. I think if we
> want to break any level of compat, then we move to 2.0, strip the
> cruft, and restart with the *same* compat restrictions. If the step to
> 2.0 is simply dropping deprecated stuff, then most users won't have a
> problem with it; only tools using our API/ABI will need to perform
> some work. Not sure what other changes would cause a step to 2.0,
> beyond a simple desire to "rm libsvn_*/deprecated.c"
I don't know that there will be some landmark event. At some point, the cost of carrying around the backward compat gets overly burdensome, and it just makes sense to loosen the restrictions, bump to 2.0, and clean everything up. Witness the amount of cleanup that has been doable in the JavaHL bindings since we repackaged and effectively gained the chance to break API compat. Such a change can be accomplished with grace (see Python 3), and is as much a communication problem as a technical one.
As for APR, if we're not going to update the deps now, I say we don't even worry about doing it until apr 2.0 ships, and then update for that platform instead. (And as far as I know, that's still a long ways out.)
Regarding the discussion about our compatibility guidelines, that might be a good point to add to the agenda for the NYC discussions in a couple of weeks. :)
-Hyrum
Re: Bump minimal APR version
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Mar 11, 2010 at 11:18, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> On Mar 11, 2010, at 9:31 AM, Mark Phippard wrote:
>> On Thu, Mar 11, 2010 at 10:25 AM, Hyrum K. Wright
>> <hy...@mail.utexas.edu> wrote:
>>> My general thoughts on stuff like this is that folks want a newer version of Subversion, they may > need to upgrade their dependencies. If they are unable or unwilling to do so, then they will just
>>> have to stick with the older version of Subversion. If these means that somebody on a RHEL 4.0
>>> box who is stuck using httpd 2.0.x can't run Subversion 1.7 without more work, tough. I suspect
>>> these folks are a relatively small number of our usership.
>>
>> I don't get this. We are willing to do things like require Python 2.4
>> (which we did in 1.6) and consider requiring APR 1.3. These sorts of
>> things impact a significant number of our users and really bring us as
>> developers only modest benefits in terms of making our lives easier.
>
> I dunno. The *vast* majority of people get a prepackaged client. As Peter mentioned elsewhere, Debian has been shipping apr 1.2.x with Subversion for some time, and I suspect that a large number of other clients have already moved to apr 1.x. The *only* people an apr version bump affects are developers and people who build Subversion from source, who are vastly in the minority. (I'd be interested to know who in the dev community still uses apr 0.9.x, for instance.)
Our longstanding policy has been "hey, feel free to upgrade svn at any
time. going from 1.x to a later version will never cause a problem."
We chose this policy so that an admin would KNOW that nothing on the
system would break if he updated the packages. No tools. No GUI
clients. No repositories. No working copies. No nothing.
The thing about a prepackaged client is a red herring. By removing
compat for 0.9.x, then httpd 2.0.x users will be shut out of 1.7 and
later. Completely. There will never be source or binaries that work in
that environment.
Strawman answer? Just don't provide packages for Apache; just the
client. Okay, great. The admin updates the client packages, which
includes libsvn_subr-1.so, which NOW links against libapr-1.so. The
2.0 httpd on that box gets restarted at some point, and loads
libapr-0.so, and then loads libsvn_subr-1.so which loads libapr-1.so.
OOPS. Or maybe that subr tries to work against libapr-0, finding the
symbols already in the address space.
Net result: admins no longer have a "safe update" policy. I think that
is a big mistake.
>> Yet, we force ourselves to jump through hoops keeping our libsvn_wc
>> API compatible, probably tripling the amount of time it takes to
>> rewrite it. When the impact on our users if we just said screw it and
>> broke the compatibility would probably be minimal. After all, the API
>> sucks how many people wrote custom tools to this level of the API as
>> opposed to libsvn_client? And most of those users would probably live
>> with the notion that at least their own code would get easier when
>> they had to update it for a new library.
>>
>> Anyway, I know we are not going to change this approach, I just think
>> we are our own worst enemy some times.
>
> I *think* what you're saying is that our compatibility guidelines are a bit screwy. If that's your assertion, I tend to agree. :)
No. He's saying if you're willing throw out one measure of
compatibility, why not the one causing us so much pain right now? (the
wc API)
> When we talk about backward compat, there are actually several dimensions we've lumped into one:
> * API compatibility
> * ABI compatibility
> * on-the-wire protocol compatibility
> * persistent storage formats (wc metadata and repos formats)
> * command line output (for scripting purposes, etc.)
>
> For a long time, we've tried very hard to keep *all* of these backward compatible, but experience has shown that most users only care about a subset of these dimensions (though that subset may differ between groups of users). As Subversion continues to evolve, we need to figure out which areas are important, and which we can drop if/when we go to 2.0.
>
> For instance, I believe that we should maintain wire protocol compat ad infinitum, even through 2.0, simply because it allows people to continue deploy a heterogeneous client/server environment. We've already practically broken our wc metadata format, and we've occasionally extended the command line output when it's made sense. (I often wonder how people who scripted against 'svn up' dealt with the new conflict summary.)
>
> Staying backward ABI compatible *forever* just isn't scalable. At some point, the costs outweigh the benefits , and I'm suggesting that maybe we should start thinking about what the costs are, and whether it makes sense to tell the 0.0001% of people who'd need to recompile to do so. (This is somewhat analogous to the decision to not upgrade pending logs in wc-ng.)
I believe the above statements about our compatibility guidelines are
orthogonal to supporting APR 0.9.x. It's a fair discussion to have,
but I believe it is a very separate and long discussion. I think if we
want to break any level of compat, then we move to 2.0, strip the
cruft, and restart with the *same* compat restrictions. If the step to
2.0 is simply dropping deprecated stuff, then most users won't have a
problem with it; only tools using our API/ABI will need to perform
some work. Not sure what other changes would cause a step to 2.0,
beyond a simple desire to "rm libsvn_*/deprecated.c"
> As Jeremy alluded to elsethread, we've continued to support platforms which aren't even supported by their respective vendors anymore. I reiterate my statement that if users want a new enough Subversion, they may need to upgrade other aspects of their systems as well. If done gracefully, the updating of compatibility can be done effectively.
>
> (FWIW, I think doing a green-field implementation of wc-ng probably would have taken just as long. The incremental approach we've taken has yield a plethora of benefits, not the least of which has been the ability to continue to leverage the existing test suite. I personally see wc-ng as a stepping stone to 2.0, but that's a discussion for another day.)
Agreed. Problems show up much much faster. The other thing is that we
use the existing code/algorithms to drive our requirements. Starting
from scratch also means (re)introducing all those edge case bugs that
the current codebase has discovered and dealth with.
Cheers,
-g
Re: Bump minimal APR version
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Mar 11, 2010, at 9:31 AM, Mark Phippard wrote:
> On Thu, Mar 11, 2010 at 10:25 AM, Hyrum K. Wright
> <hy...@mail.utexas.edu> wrote:
>
>> My general thoughts on stuff like this is that folks want a newer version of Subversion, they may > need to upgrade their dependencies. If they are unable or unwilling to do so, then they will just
>> have to stick with the older version of Subversion. If these means that somebody on a RHEL 4.0
>> box who is stuck using httpd 2.0.x can't run Subversion 1.7 without more work, tough. I suspect
>> these folks are a relatively small number of our usership.
>
> I don't get this. We are willing to do things like require Python 2.4
> (which we did in 1.6) and consider requiring APR 1.3. These sorts of
> things impact a significant number of our users and really bring us as
> developers only modest benefits in terms of making our lives easier.
I dunno. The *vast* majority of people get a prepackaged client. As Peter mentioned elsewhere, Debian has been shipping apr 1.2.x with Subversion for some time, and I suspect that a large number of other clients have already moved to apr 1.x. The *only* people an apr version bump affects are developers and people who build Subversion from source, who are vastly in the minority. (I'd be interested to know who in the dev community still uses apr 0.9.x, for instance.)
> Yet, we force ourselves to jump through hoops keeping our libsvn_wc
> API compatible, probably tripling the amount of time it takes to
> rewrite it. When the impact on our users if we just said screw it and
> broke the compatibility would probably be minimal. After all, the API
> sucks how many people wrote custom tools to this level of the API as
> opposed to libsvn_client? And most of those users would probably live
> with the notion that at least their own code would get easier when
> they had to update it for a new library.
>
> Anyway, I know we are not going to change this approach, I just think
> we are our own worst enemy some times.
I *think* what you're saying is that our compatibility guidelines are a bit screwy. If that's your assertion, I tend to agree. :)
When we talk about backward compat, there are actually several dimensions we've lumped into one:
* API compatibility
* ABI compatibility
* on-the-wire protocol compatibility
* persistent storage formats (wc metadata and repos formats)
* command line output (for scripting purposes, etc.)
For a long time, we've tried very hard to keep *all* of these backward compatible, but experience has shown that most users only care about a subset of these dimensions (though that subset may differ between groups of users). As Subversion continues to evolve, we need to figure out which areas are important, and which we can drop if/when we go to 2.0.
For instance, I believe that we should maintain wire protocol compat ad infinitum, even through 2.0, simply because it allows people to continue deploy a heterogeneous client/server environment. We've already practically broken our wc metadata format, and we've occasionally extended the command line output when it's made sense. (I often wonder how people who scripted against 'svn up' dealt with the new conflict summary.)
Staying backward ABI compatible *forever* just isn't scalable. At some point, the costs outweigh the benefits , and I'm suggesting that maybe we should start thinking about what the costs are, and whether it makes sense to tell the 0.0001% of people who'd need to recompile to do so. (This is somewhat analogous to the decision to not upgrade pending logs in wc-ng.)
As Jeremy alluded to elsethread, we've continued to support platforms which aren't even supported by their respective vendors anymore. I reiterate my statement that if users want a new enough Subversion, they may need to upgrade other aspects of their systems as well. If done gracefully, the updating of compatibility can be done effectively.
(FWIW, I think doing a green-field implementation of wc-ng probably would have taken just as long. The incremental approach we've taken has yield a plethora of benefits, not the least of which has been the ability to continue to leverage the existing test suite. I personally see wc-ng as a stepping stone to 2.0, but that's a discussion for another day.)
I'll now pause, to let Greg flame me. :)
-Hyrum
Re: Bump minimal APR version
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Mar 11, 2010 at 10:25 AM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> But does httpd-2.0.x *require* apr 0.9.x? For a long time, Subversion shipped with apr 0.9.x, but
> we've always been compatible with the 1.x series. I wonder if http 2.0.x is similar.
Yes it requires 0.9.x.
> My general thoughts on stuff like this is that folks want a newer version of Subversion, they may > need to upgrade their dependencies. If they are unable or unwilling to do so, then they will just
> have to stick with the older version of Subversion. If these means that somebody on a RHEL 4.0
> box who is stuck using httpd 2.0.x can't run Subversion 1.7 without more work, tough. I suspect
> these folks are a relatively small number of our usership.
I don't get this. We are willing to do things like require Python 2.4
(which we did in 1.6) and consider requiring APR 1.3. These sorts of
things impact a significant number of our users and really bring us as
developers only modest benefits in terms of making our lives easier.
Yet, we force ourselves to jump through hoops keeping our libsvn_wc
API compatible, probably tripling the amount of time it takes to
rewrite it. When the impact on our users if we just said screw it and
broke the compatibility would probably be minimal. After all, the API
sucks how many people wrote custom tools to this level of the API as
opposed to libsvn_client? And most of those users would probably live
with the notion that at least their own code would get easier when
they had to update it for a new library.
Anyway, I know we are not going to change this approach, I just think
we are our own worst enemy some times.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Bump minimal APR version
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Mar 10, 2010, at 7:05 PM, Greg Stein wrote:
> On Wed, Mar 10, 2010 at 13:34, Hyrum K. Wright
> <hy...@mail.utexas.edu> wrote:
>> I'd like to propose that we bump the minimal APR version from the current 0.9.7 to something a bit more modern, say 1.3.0.
>>
>> 1.3.0 was released in June 2008, and we are already conditionally using parts of it. In fact, in the 1.6.x series, we've even shipped APR/APR-util 1.3.x in the deps tarball. Neither of these practices have caused consternation among our users, who almost exclusively use the system-provided APR (or the one compiled into their client).
>>
>> We are currently planning on making ra_serf the default dav provider in Subversion 1.7. As ra_serf depends on serf, and the latter requires APR at least 1.x, I think it reasonable that we bump our minimal required APR version as well.
>>
>> In that past, I recall some pressing reason for still keeping 0.9.7 as the minimal required version, but I don't recall what those arguments were, nor do I think they are still relevant.
>>
>> Thoughts?
>
> As I said on IRC, I believe the requirement is caused by httpd 2.0.x
> requiring APR 0.9.x. If we bump the requirement, then mod_dav_svn
> could not be loaded into httpd 2.0.x. I'm guessing there are plenty of
> 2.0 servers out there.
>
> Ah. Just downloaded the 2.0.63 httpd tarball and verified it comes with 0.9.x.
But does httpd-2.0.x *require* apr 0.9.x? For a long time, Subversion shipped with apr 0.9.x, but we've always been compatible with the 1.x series. I wonder if http 2.0.x is similar.
My general thoughts on stuff like this is that folks want a newer version of Subversion, they may need to upgrade their dependencies. If they are unable or unwilling to do so, then they will just have to stick with the older version of Subversion. If these means that somebody on a RHEL 4.0 box who is stuck using httpd 2.0.x can't run Subversion 1.7 without more work, tough. I suspect these folks are a relatively small number of our usership.
-Hyrum
Re: Bump minimal APR version
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Mar 10, 2010 at 13:34, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> I'd like to propose that we bump the minimal APR version from the current 0.9.7 to something a bit more modern, say 1.3.0.
>
> 1.3.0 was released in June 2008, and we are already conditionally using parts of it. In fact, in the 1.6.x series, we've even shipped APR/APR-util 1.3.x in the deps tarball. Neither of these practices have caused consternation among our users, who almost exclusively use the system-provided APR (or the one compiled into their client).
>
> We are currently planning on making ra_serf the default dav provider in Subversion 1.7. As ra_serf depends on serf, and the latter requires APR at least 1.x, I think it reasonable that we bump our minimal required APR version as well.
>
> In that past, I recall some pressing reason for still keeping 0.9.7 as the minimal required version, but I don't recall what those arguments were, nor do I think they are still relevant.
>
> Thoughts?
As I said on IRC, I believe the requirement is caused by httpd 2.0.x
requiring APR 0.9.x. If we bump the requirement, then mod_dav_svn
could not be loaded into httpd 2.0.x. I'm guessing there are plenty of
2.0 servers out there.
Ah. Just downloaded the 2.0.63 httpd tarball and verified it comes with 0.9.x.
Cheers,
-g
Re: Bump minimal APR version
Posted by Peter Samuelson <pe...@p12n.org>.
[Hyrum K. Wright]
> I'd like to propose that we bump the minimal APR version from the
> current 0.9.7 to something a bit more modern, say 1.3.0.
Only if we drop our "library ABI is compatible all the way back to 1.0"
assertion. At the time Subversion 1.0 was released, I guarantee nobody
built it against apr 1.3. If anybody even built it against apr 1.0,
I'll be surprised.
I don't really have a horse in this race - as Debian maintainer I
switched from apr 0.9 to 1.2 long ago (in such a way as to honor
Debian's own commitment to only change ABIs under strict procedures
that do not require a recompile-every-consumer flag day).
But if we still want to say we support binary compatibility that far
back, well, we can't drop support for apr 0.9.
Peter