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

Re: Announcing MaxSVN

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Wed, 16 Sep 2015 11:02:43 +0200

On 13 September 2015 at 23:52, Stefan <luke1410_at_gmx.de> wrote:
> Hi Ivan,
>
Hi Stefan!

>> On 7 September 2015 at 18:47, Stefan <luke1410_at_gmx.de> wrote:
>>>
>>> Hi,
>>>
>>> I'm pleased to announce the availability of a new distribution of SVN
>>> called: "MaxSVN".
>>> In contrast to other SVN distributions this one is a bit different since
>>> it
>>> aims towards being used primarily to support SVN development rather than
>>> being used in production environments.
>>>
>>> Its primary purpose is to test and identify issues of SVN against the
>>> latest
>>> build tools and dependencies on Windows.
>>>
>>> It can however also be useful in other situations like if you wanna check
>>> whether a current development branch solved a particular issue or to
>>> check
>>> out the new features in an upcoming SVN release before it becomes
>>> available
>>> as part of a final release.
>>>
>>> Please note once more that I strongly suggest against using MaxSVN in
>>> your
>>> daily productive use. Please stick with one of the already available
>>> Windows
>>> distributions. A list of these can be found on the MaxSVN webpage:
>>> http://www.luke1410.de/typo3/index.php?id=97
>>>
>>> Also understand that MaxSVN is a product distributed, maintained and
>>> created
>>> by myself and is not directly associated with the Apache Subversion
>>> project.
>>>
>>> The latest current available builds are:
>>> - 1.7.22.2 (current latest 1.7 released version)
>>> - 1.8.14.2 (current latest 1.8 released version)
>>> - 1.8.15.1 (current 1.8 preview version)
>>> - 1.9.1.2 (current latest 1.9 released version)
>>> - 1.9.2.1 (current 1.9 preview version)
>>> - 1.10.0.2 (current 1.10 preview version)
>>>
>>> Feel free to send any feedback directly to me by mail or use the
>>> bugtracker
>>> at http://www.luke1410.de:8090/browse/MAXSVN to add bugreports/feature
>>> requests.
>>>
>> May I suggest to rename branch and trunk builds version to something
>> like 1.9.x-dev-rXXXX and 1.10.x-dev-rXXX? Never replace 'x' with the
>> current version patch version. I.e. '1.9.x-dev-r1701757'.
>>
>> Because versions like 1.9.2.1 may confuse users. It's very hard to
>> find difference between 1.9.1.2 and 1.9.2.1 to distinguish official
>> releases from development builds.
>>
>> Thanks!
>
> I agree with u that the version numbering is not too clear and I also tend
> to agree that adding the revision number to the version number makes sense
> given the target audience of MaxSVN.
>
> If I understand u right, then u are suggesting not to use SVN's patch
> version in MaxSVN version numbering scheme. I thought having that directly
> in the version number available would actually benefit users, because they
> would directly see which SVN version a MaxSVN version is based on.
>
You are understand my correctly. My point that you cannot call
something build from 1.9.x branch as 1.9.1 or 1.9.2. The only build
from official distribution or tag should have patch version in version
number IMO. For example at which point you're going to change patch
version of branch builds? We change it at arbitrary time: sometimes
it's done immediately after creating, sometimes later.

> I also think that Bert's suggestion to use the "dev" marker for versions
> which are based on a not-yet released build is quite good and drop that
> marker once a build is based on a released version.
>
> What's ur opinion on using the following scheme instead:
> 1.9.x-y-rxxx-dev for versions not yet released
> 1.9.x-y-rxxx for versions based on SVN versions which are already released
>
> x is the current minor version of the SVN version
> y is a running number for MaxSVN builds
> rxxx is the SVN revision a build is based on
>
> So in case of the current 1.9 MaxSVN releases this is how with the other
> scheme things would look like:
> 1.9.0.1 -> 1.9.0-1-r1692833
What is the reason to include revision number for tag builds? In this
case you reduce difference between tag and branch builds, which may
increase user confusion. IMO tag and branch builds should be very
distinguishable from each other.

> 1.9.1.1 -> 1.9.1-1-r1694136-dev
> 1.9.1.2 -> 1.9.1-2-r1698174
> 1.9.2.1 -> 1.9.2-1-r1701493-dev
>
I find proposed scheme very confusing for users. It already confused
users on tsvn-users list: they have an impression that 1.9.2 is
already released, because they noticed 1.9.2-something builds on your
website.

-- 
Ivan Zhakov
Received on 2015-09-16 11:03:21 CEST

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.