You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Max Bowsher <ma...@ukf.net> on 2005/10/04 13:24:26 UTC
Version compatibility of mod_*_svn to libsvn_*
Did we ever decide a conclusive answer to the following question?:
Is mod_{dav,authz}_svn:
EITHER (a) a client of the subversion libraries like any other, hence a
mod_dav_svn should work with libsvn_* libraries of the same, _or any
greater_ 1.x version - e.g. 1.2.x mod_dav_svn with 1.3.x libsvn_* libs.
OR (b) an integral part of the core subversion code, and thus should only be
used as part of a matched set of equal-versioned components.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Version compatibility of mod_*_svn to libsvn_*
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 10/4/05, Daniel Rall <dl...@finemaltcoding.com> wrote:
> (a) sounds like way more trouble than it's worth.
Yes, my memory is that we settled on (b).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Version compatibility of mod_*_svn to libsvn_*
Posted by Julian Foad <ju...@btopenworld.com>.
Greg Hudson wrote:
>
> But people definitely upgrade from maintenance releases to later
> releases, and if they're allowed to mix and match Subversion libraries,
> then they'll run afoul of the compatibility policy as understood by Max.
> (Unless we also add the double-underscore symbols on the trunk and
> maintain them as if they were part of the public API. We've done that
> belatedly in one instance, because people *do* sometimes use mismatched
> versions of mod_dav_svn due to vendor packaging issues, and a
> maintenance release caused mod_dav_svn to be using double-underscore
> symbols.)
We need to make a distinction between the Libraries and the Apache Modules. It
seems that we can't lump both into a monolithic installation, required to stay
as a matched set, if the modules are being distributed separately. In that
case, we need to state clearly that the modules are clients of the Subversion
Libraries, and so must follow compatibility rules. Yes?
(I don't think there's any doubt that the Libraries should be required to stay
as a matched set.)
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Version compatibility of mod_*_svn to libsvn_*
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2005-10-09 at 21:11 -0500, kfogel@collab.net wrote:
> Greg Hudson <gh...@MIT.EDU> writes:
> > If it's so dastardly to use double-underscore symbols like this, what
> > should we do when we need to add a new libsvn_subr API to fix a bug, and
> > want to backport that bug to a previous release? In the past, we've
> > converted the new API to a double-underscore symbol. I don't think I've
> > seen you or Karl address this point so far.
>
> I guess I make a distinction between recommended practice and mildly
> klugey things done to get a fix into a maintenance line. People don't
> look at maintenance lines when they're doing development, generally;
> what's important is that trunk reflect The Way Things Ought To Be.
But people definitely upgrade from maintenance releases to later
releases, and if they're allowed to mix and match Subversion libraries,
then they'll run afoul of the compatibility policy as understood by Max.
(Unless we also add the double-underscore symbols on the trunk and
maintain them as if they were part of the public API. We've done that
belatedly in one instance, because people *do* sometimes use mismatched
versions of mod_dav_svn due to vendor packaging issues, and a
maintenance release caused mod_dav_svn to be using double-underscore
symbols.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Version compatibility of mod_*_svn to libsvn_*
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> If it's so dastardly to use double-underscore symbols like this, what
> should we do when we need to add a new libsvn_subr API to fix a bug, and
> want to backport that bug to a previous release? In the past, we've
> converted the new API to a double-underscore symbol. I don't think I've
> seen you or Karl address this point so far.
I guess I make a distinction between recommended practice and mildly
klugey things done to get a fix into a maintenance line. People don't
look at maintenance lines when they're doing development, generally;
what's important is that trunk reflect The Way Things Ought To Be.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Version compatibility of mod_*_svn to libsvn_*
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2005-10-09 at 16:46 +0100, Max Bowsher wrote:
> >>> EITHER (a) a client of the subversion libraries like any other, hence a
> >>> mod_dav_svn should work with libsvn_* libraries of the same, _or any
> >>> greater_ 1.x version - e.g. 1.2.x mod_dav_svn with 1.3.x libsvn_* libs.
> >>>
> >>> OR (b) an integral part of the core subversion code, and thus should
> >>> only
> >>> be used as part of a matched set of equal-versioned components.
> Ummm.... What on earth?
> I asked expecting to receive a quick confirmation: "(a), obviously".
> Now I've taken the time to think it through, I realize that it absolutely
> has to be (a) without question, because that is a natural consequence of our
> compatibility rules, unless we do something dastardly like use supposedly
> library-private APIs in mod_dav_svn.
You're certainly not going by my understanding of the compatibility
rules, nor do I consider it dastardly to use double-underscore symbols
between libraries.
If it's so dastardly to use double-underscore symbols like this, what
should we do when we need to add a new libsvn_subr API to fix a bug, and
want to backport that bug to a previous release? In the past, we've
converted the new API to a double-underscore symbol. I don't think I've
seen you or Karl address this point so far.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Version compatibility of mod_*_svn to libsvn_*
Posted by Max Bowsher <ma...@ukf.net>.
Daniel Rall wrote:
> On Tue, 04 Oct 2005, Marcus Rueckert wrote:
>
>> On 2005-10-04 14:24:26 +0100, Max Bowsher wrote:
>>> Is mod_{dav,authz}_svn:
>>>
>>> EITHER (a) a client of the subversion libraries like any other, hence a
>>> mod_dav_svn should work with libsvn_* libraries of the same, _or any
>>> greater_ 1.x version - e.g. 1.2.x mod_dav_svn with 1.3.x libsvn_* libs.
>>>
>>> OR (b) an integral part of the core subversion code, and thus should
>>> only
>>> be used as part of a matched set of equal-versioned components.
>>
>> iirc it was b. there were some debian bug about it. and the team replied
>> the API rules only applies to external APIS. not to the internal ones.
>
> (a) sounds like way more trouble than it's worth.
Ummm.... What on earth?
I asked expecting to receive a quick confirmation: "(a), obviously".
Now I've taken the time to think it through, I realize that it absolutely
has to be (a) without question, because that is a natural consequence of our
compatibility rules, unless we do something dastardly like use supposedly
library-private APIs in mod_dav_svn.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Version compatibility of mod_*_svn to libsvn_*
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Tue, 04 Oct 2005, Marcus Rueckert wrote:
> On 2005-10-04 14:24:26 +0100, Max Bowsher wrote:
> > Is mod_{dav,authz}_svn:
> >
> > EITHER (a) a client of the subversion libraries like any other, hence a
> > mod_dav_svn should work with libsvn_* libraries of the same, _or any
> > greater_ 1.x version - e.g. 1.2.x mod_dav_svn with 1.3.x libsvn_* libs.
> >
> > OR (b) an integral part of the core subversion code, and thus should only
> > be used as part of a matched set of equal-versioned components.
>
> iirc it was b. there were some debian bug about it. and the team replied
> the API rules only applies to external APIS. not to the internal ones.
(a) sounds like way more trouble than it's worth.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Version compatibility of mod_*_svn to libsvn_*
Posted by Marcus Rueckert <da...@web.de>.
On 2005-10-04 14:24:26 +0100, Max Bowsher wrote:
> Did we ever decide a conclusive answer to the following question?:
>
>
> Is mod_{dav,authz}_svn:
>
> EITHER (a) a client of the subversion libraries like any other, hence a
> mod_dav_svn should work with libsvn_* libraries of the same, _or any
> greater_ 1.x version - e.g. 1.2.x mod_dav_svn with 1.3.x libsvn_* libs.
>
> OR (b) an integral part of the core subversion code, and thus should only
> be used as part of a matched set of equal-versioned components.
iirc it was b. there were some debian bug about it. and the team replied
the API rules only applies to external APIS. not to the internal ones.
darix
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org