Simon Large wrote:
> On 14 February 2010 15:49, Lieven Govaerts <svnlgo_at_mobsol.be> wrote:
>> On Sat, Feb 13, 2010 at 10:36 PM, Stefan Fuhrmann
>>
>>> * Users will be confused in the beginning and be
>>> annoyed later on. ("what is the matching tool set
>>> to install? I hate that. They obviously lost focus.
>>> Time to change").
>> More likely. The TSVN version numbering has been aligned with svn
>> version numbering for so long that any change here will be very
>> confusing.
>>
>> Especially in an enterprise environment, where people are using
>> Subclipse, JavaHL, SVNKit, TortoiseSVN and the command line tools all
>> on the same working copies.
>
> But Subclipse version numbers are not synced to svn version either
> (currently 1.0.7)
> SVNKit is at 1.3.2 and JavaHL is (I think) different also. So as long
> as we make a clear break difference in the numbering scheme I cannot
> see why there should be a problem.
I'm hard pressed to find an application with a version number
LARGER than the library version it uses. I'm +100 for getting
a release with new features (LOVE being able to see externals in
the repo browser), but -1 on using a 1.7.x version number.
2.0.x just doesn't seem right either and I've never been a fan of years
in the release numbers. 1.6.10x (or 1.6b.x) is the best balance of
numbering in my book. In hindsight it probably would have been better
to never try and keep them synced, but moving to 1.7.x when so
many people are looking forward to the 1.7 svn changes that
include working copy changes would cause confusion. I already have
a hard enough time explaining that TortoiseSVN 1.6.7 is actually
the "latest" version...
Kevin R.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2447614
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-02-15 04:29:31 CET