On 19/09/2015 16:43, Evgeny Kotkov wrote:
> 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
You are absolutely right here and I should have seen that before. Didn't
take that (obvious) point into account at all.
I'll come-up with a working version scheme which won't have potential
for causing this misinterpretation and will make sure that the next
releases will use that other scheme.
Think the solution will either be to restart my own version numbering
which is completely independent from SVN's or go with the alternative
Received on 2015-09-19 16:55:11 CEST