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

Re: 1.7.0

From: Joseph Galbraith <galb_at_vandyke.com>
Date: Sat, 13 Feb 2010 09:05:25 -0700

On 2/13/2010 08:30, Stefan Küng wrote:
> 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.

I find that I'm very strongly for a new version... and while I agree
with others that there may be some confusion due to the past apparent
linkage with the svn library major and minor versions, I also agree
that it doesn't warrant a 2.x release either.

I'm not a big fan of the 1.6.100 idea either. That just seems...
ugly I guess.

In the end, I think the distress of having the version numbers unsynched
will pass, and as Stefan said, then we never have to worry about it
again and we can have our own release cycle based on whatever version
of SVN is the latest when we're ready to release.

So in the end, I'm strongly +1 for a new release regardless of what
version we call it, with a bias towards 1.7.0 as the name.

Thanks,

Joseph

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2447299

To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-02-13 17:05:19 CET

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

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