On 15 February 2010 22:00, Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de> wrote:
> On 14 Feb 2010 19:47:04, Stefan Küng wrote:
>>
>> In the thread with subject "1.7.0", there wasn't really a consensus.
>> Well, nobody objected to a release with new features, but there was
>> quite a controversy about what version number to use for this. None of
>> the suggestions really got a consensus.
>>
> Well, a few hours on a weekend may not be enough to
> reach a consensus on such a seemingly sensitive topic ;)
>
> But as Simon pointed out, there is at least some progress
> in the discussion. As of now, there are two proposals
> being considered:
>
> * 1.6 R2
> The number on the third level is almost a technical detail
> that might not be relevant to most users (see Windows 5.0,
> 5.1 and 5.2). Challenge: make the "R2" part as unmistakable
> as possible.
>
> * year-based versioning
> Minor details like 2010 vs. 10 have not yet decided upon.
> Personally, I have no preference here for 2010.0, 10.0,
> 2010.3 or 10.3 (3 is for the month).
... or some other scheme that we haven't touched on yet. But yes,
basically the two options are to keep major.minor in sync with
subversion and use some other differentiator, or make the version
numbering so completely different that it cannot cause confusion.
Although some want to keep the sync at any cost, the main argument is
only about causing confusion by using 1.7, or raising expectations by
using 2.0. There has not been much argument against the date-based
versions.
IMHO 1.6-R2 is not a good way of introducing new features, and creates
its own confusion about what is stable. You could style it after
Microsoft service packs and call it 1.6-SP1 but even MS is mainly
releasing bug fixes and not new features (although admittedly this is
because they want you to pay for new features by buying their next
OS).
> Iff we can address the challenge of the first variant, it would
> probably be the one that is closed to our past scheme.
>>
>> So I think the only way to solve this problem is to merge the changes we
>> did to make TSVN work better on Win7 back to the 1.6.x branch and have
>> it released there.
>>
> I assumed that this wasn't possible - at least not w/o breaking
> w2k compatibility. A "normal" bug fix release is, of course, the
> best solution.
>>
>> Since the Win7 changes are really the only changes that are important
>> (users can live quite well without the other new features, even though
>> they're great), we can keep the current version numbering scheme and
>> avoid any confusion a new scheme might cause.
>>
> But perhaps, we should try to reach a consensus on an alternate
> versioning scheme irrespectively. There is still the possibility of
> SVN 1.7 being delayed far into next year - despite my crystal
> ball estimation of late Q3. Having the *option* of intermediate
> releases would be desirable.
+1
Although several people have commented on the desirability of keeping
the revisions in sync, it is IMHO only a historical convenience and no
other subversion client that I found has limited itself in this way,
nor the clients for other VCSs. Current discussions on the SVN dev
list are not making the 1.7 release look any earlier and there are
quite a few features in TSVN that it seems a shame to hold back just
to make the numbers line up.
>> So I'll start merging the important Win7 changes to the 1.6.x branch
>> soon.
> Intended release with SVN 1.6.10 or earlier?
As it scratches some real itches for Win7 users then I think it merits
a release sooner, and if it doesn't break Win2K compatibility then
there is no need to use a different major.minor.
Simon
--
: ___
: 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=2447937
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-02-16 00:59:42 CET