[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r8731 - trunk/subversion/include

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-02-19 22:50:47 CET

kfogel@collab.net wrote:

>Branko Čibej <brane@xbc.nu> writes:
>>Committers, please review this. We should get it into the 1.0.x branch
>>in time for tomorrow's beta1.
>[Responding in two threads, because this has been mentioned in two
>threads now.]
>I'm very confused :-).
>We already had a tested patch that works for 1.0.0. Maybe you didn't
>see it? (Or was there something wrong with it?)
Two things were wrong with that patch:

    * It doesn't deal with SVN_VER_NUMTAG
    * It doesn't solve the problem of "svn --version" printing "1.0.0
      ()" in the released -- i.e., non-Beta -- version.

My patch addresses both these issues, that's why I committed it.

>Meanwhile, I don't understand why this patch bumps anything to 38. We
>should be done with those interim numbers now. Both 1.0.x and trunk
>will have SVN_VER_MAJOR = 1.
Exactly -- "will have". 1.0 is not out yet, nor do we yet have a beta.
Immediately after the 1.0.x branch starts displaying "1.0.0 (beta 1)"
and "1.0.0-beta1, trunk should be changed to say "1.1.0 (dev build)" and

> Trunk will get SVN_VER_MINOR = 1, while
>1.0.x gets SVN_VER_MINOR = 0. SVN_VER_PATCH just depends on what
>release it is.

Exactly. Again, in the future.
The reason I bumped minor and not major on trunk is that I believe we
should bump major on the branch 1.0 first.

>I don't quite understand the rest of the motivations in this change.
>That's okay: we can talk about it while 1.0.0 goes out the door,
>because we have a simpler patch for 1.0.0.
Simpler, but wrong.

Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 19 22:51:03 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.