Greg Hudson <ghudson@MIT.EDU> writes:
> > There is one aspect of Subversion not addressed by the APR guidelines:
> > client/server compatibility.
>
> Also working-copy compatibility and FS compatibility.
Good points! How about this:
Working copy and repository formats are backward- and
forward-compatible for all patch releases in the same minor series.
They are backward-compatible for all minor releases in the same
major series; however, a minor release is allowed to make a working
copy or repository that doesn't work with previous minor releases,
where "make" could mean "upgrade" as well as "create".
(I'm keeping this thread, by the way, with the intention of recording
this stuff in HACKING after discussion has settled.)
> > So the patch levels in the 1.0.x line would be, in order, 1.0.1,
> > 1.0.2, 1.0.3, etc. The API-but-not-ABI-compatible releases in the 1.x
> > line would be 1.2.0, 1.3.0, 1.4.0, etc.
>
> I think you misread the APR versioning guidelines. 1.1.0 does not get
> to break the 1.0 ABI. That has to wait for 2.0 just like an
> incompatible API change has to wait.
I did misread them, you're right.
The important thing about patch releases is really that they are
*both* forward- and backward-compatible. Minor releases might only be
backward-compatible, both ABI- and API-wise...
> What 1.1.0 gets to do is add functionality, such that a *downgrade* from
> 1.1.x to 1.0.x might be traumatic in terms of API or ABI compatibility
> or other issues. (A downgrade from 1.0.2 to 1.0.1 should not be
> traumatic except insofar as it will re-introduce all the bugs we fixed
> in 1.0.2.)
... which is exactly what you say above.
I still think the guidelines are excellent, by the way, even now that
I understand them.
Justin Erenkrantz wrote:
> Right. I think Karl might say that we should punt this, but I dunno.
>
> Case in point was reworking svn_client_blame to take a new argument.
> What should we do? Does adding svn_client_blame2 make sense in 1.1,
> or should we just break our ABI by changing svn_client_blame's
> signature in 1.1?
>
> I think if we answer that, we're pretty much agreed on everything.
Well, changing svn_client_blame's signature in 1.1 would be not merely
an ABI change, but an API change as well, thus simply not allowed. We
have to do it by adding svn_client_blame2.
So I think the answer there is pretty clear.
David Summers asked:
> So in this scheme of things, is the current 0.35 = 1.0.0 (beta 1)
> 0.36 = 1.0.0 (beta 2)
> 0.37 = 1.0.0 (beta 3)
> 0.38 = 1.0.0 (beta 4)
> ????
>
> If so, would it be wise to go ahead and switch to that nomenclature?
Conceptually correct, but let's not switch to the new nomenclature
until after 1.0.0 is out. We've been using the interim release system
for a long time, people understand it, and we already said what 0.37
means. If we release the same code under a new name, we'll only
create confusion.
rl-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 29 21:59:22 2004