On 13.02.2010 16:17, Jean-Marc van Leerdam wrote:
> Hi,
>
> On 13 February 2010 15:27, Ulf Zibis<Ulf.Zibis_at_gmx.de> wrote:
>> +1
>>
>> May be call it 1.6.10.
>> (Example: When Sun's Java SDK had a big enhancement, they jumped from
>> 1.6u7 directly to 1.6u10)
>>
>> ... and later 1.6.18 when linked against SVN 1.6.8
>> Or: 1.6.100 ... 1.6.108
>>
>> > There is certainly precedent for *not* staying in sync.
>> - "1000 flies won't be in error" IOW: others should follow TSVN's good
>> example
>> - TSVN users are used to have the versions synched since long, so they
>> probably would be more irritated and astonished than others.
>>
>> > TortoiseHG 0.9.3 links against Mercurial 1.4.3
>> > TortoiseGit 1.3.x uses gitdll 1.6.x
>> > TortoiseCVS 1.10.x uses CVS 1.11.x
>>
>> This could express, that those T versions are in delay, offering ALL lib
>> features in their GUI.
>> ... but vice-versa doesn't make sense.
>>
>
> If you want to abandon the link between TSVN major and SVN major
> version (so no more TSVN 1.n == SVN 1.n), then I would suggest to go
> to TSVN 2.x and link to SVN 1.y. There should be no confusion then.
>
> Having a TSVN 1.7.x that links to SVN 1.6.y, and after that TSVN 1.8.n
> that will link to SVN 1.7.m will be confusing for an indefinite
> period.
>
> An alternative can be to temporarily lift the 'branch 1.x receives bug
> fixes only' rule until SVN is ready to release new versions more
> frequently again.
>
> I would go for 2.0 and disconnect the TSVN versioning scheme from the
> SVN releases.
Ok, so nobody seems to object to a release with new features not in sync
with the svn lib.
But there are different opinions about the version number. So I guess I
have to express my own too:
(to clear up what version numbers we're talking about, here a little
naming convention:
1.6.7 means '1' is the major version number, '6' is the minor version
number, and '7' is the micro version number)
* we never ever stated that the TSVN version number is in any way linked
to the svn library. It just happened to coincide, but that was just for
convenience. And whenever svn 'skipped' a few micro versions (e.g.,
1.6.7 and 1.6.8 of the svn lib were never released), the version numbers
didn't match anymore. Just look at the current official release: TSVN
1.6.7, linked to svn 1.6.9.
* the TSVN installer filename has *both* version numbers in it. The svn
version it is linked against is mentioned in the installer name.
Something other projects don't do and forces users to look it up on the
website/release notes. With TSVN that's much easier.
* We did state however that any .x release is a *stable* release with no
new features. That new features would get only into minor release number
changes. So any new version with new features can't be named 1.6.x, not
even 1.6.100 or anything like that. I *has* to have a new minor version
increase.
* That leaves two options to name the new version: 1.7.0 or 2.0.0. I'd
like to go with 1.7.0 because we're still using the same svn lib. A
major number change IMHO requires a lot more changes.
* another advantage to have a new major/minor version number is that we
get rid of the sync with the svn version number for good. I never was
quite happy with that anyway, since it blocked us from having our own
release timeframe.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2447291
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-02-13 16:31:00 CET