Re: PATCH: $Header$ keyword support (now with proper log message)

On Wednesday 15 September 2004 10:43, Garrett Rooney wrote:
> The problem is that the client migh thave built with a different version
> of the header files, and according to our versioning rules it's
> perfectly valid for them to have done so.

Ah, I see. That's the key point here. If you allow me to ask, why is this
allowed? This doesn't add much value (I mean, how often would you grab a new
version of the SDK libraries without also grabbing the new headers EVEN if
they were claimed to be compatible. Call me paranoid, but I never do that)
yet it puts a major showstopper to any enhancement until the next major
release.

I am in no position to question your development style, but I ask you to
consider a slightly different way:

1. The API is comprised of a set of header files and libraries and must be
treated as a whole. A client using a given version of a library MUST also be
compiled with the corresponding set of headers.

2. The API is guaranteed to be 100% backward compatible on ANY release (major,
minor or a bugfix). That means, any client using the API of a given version
is guaranteed to work with any newer version of the API.

3. The API is NOT guaranteed to be forward compatible (even though the
development team will attempt to prevent incompatibilities as long as it
doesn't hurt the innovation). A client built with a given version of the API
is not guaranteed to *compile* (this part is crucial - incompatibilities must
surface at the compile time) using a previous version of the API.

This is the usual rules of engagement of an API game and it gives enough
flexibility to both the clients and the API providers. I hope there is no
reason Subversion cannot play by those rules. I mean, there should be no
reason, as Subversion is just yet another system with an SDK and a published
API, which is in no way different from other such systems out there be it
Motif, or GTK, or CORBA, or MPI.

P.S. Finally, just playing the Devil's advocate, there is a counterexample -
libc. However, the libc public API has been static for a very long time which
definitely allows for a different treatment of that particular library.

Regards,

-- 
Alexander L. Belikoff
PGP/GPG fingerprint: 0D58 A804 1AB1 4CD8 8DA9 424B A86E CD0D 8424 2701
(http://pgp5.ai.mit.edu for the key)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org