[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: Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
Date: Sat, 19 Sep 2015 17:43:10 +0300

Stefan Hett <luke1410_at_gmx.de> writes:

> I'd imagine the following style could work (it's related to the version
> numbering from Visual Assist X (from Wholetomato)):
> - MaxSVN-1.9.1-x64 (build 1)
> - MaxSVN-1.9.2-dev-r1701493-x64 (build 1)
> - MaxSVN-1.10.0-dev-r1701493-x64 (build 1)

Let me try to rephrase myself — I don't think that the exact details of the
versioning scheme are that important. What is important, however, is whether
the scheme uses or doesn't use non-existing versions of Subversion in it.

For instance, "MaxSVN-1.9.2-something" contains version 1.9.2 that doesn't
exist. "MaxSVN-1.10.0-something" contains version 1.10.0 that also doesn't
exist. These versions are based on two arbitrary states of /branches/1.9.x
and /trunk, respectively, but they also are indexed by the search robots and
have a chance of showing up in the results for a person who is looking for
Subversion 1.9.2 or, at some point, for Subversion 1.10.

We could have people misinterpreting these versions and telling us: "So, I
downloaded Subversion 1.10, and it corrupted my data", even though there is
no Subversion 1.10 yet, and they were just using the /trunk build labeled as
1.10. And there is not much that can be done at this point.

I think that you can choose any scheme that works best for you and is suitable
for your workflow, but could you please ensure that binary packages that you
publish do not include the versions of Subversion that don't exist at the
moment?

Thanks.

Regards,
Evgeny Kotkov
Received on 2015-09-19 16:49:08 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.