For once this is not a major concern for MaxSVN, since this aims purely
for development/testing and not actual usage as an SVN client in
production environment.
For 1.10 builds there's also an additional note pointing that fact out
on the download page.
Furthermore, the dev builds of 1.10 are all suffixed with -dev-rXXXX.
Honestly, given that the user base is not aiming for "normal" users, I
don't see that much a problem here. It certainly would be a different
story, if MaxSVN was aiming for a different audience.
Regards,
Stefan
Just stating the obvious again: Any sources from trunk or a future
1.10.x branch before 1.10.0 is released is not 1.10 and may be 100%
incompatible with the real 1.10 versions.
Once 1.10 is released how are your users going to see that all the pre
1.10.0.773 (assuming 772 dev builds) are not 1.10.0 while 1.10.0.773 is?
I use something like 1.9.9993 as marker for versions like this to have
a 1.10.0.0 version as version that is higher than all pre releases.
It wouldn't be the first time that we changed a wc or repository
format weeks before a .0 release.
Bert
------------------------------------------------------------------------
From: Stefan <mailto:luke1...@gmx.de>
Sent: 19-9-2015 18:12
To: Evgeny Kotkov <mailto:evgeny.kot...@visualsvn.com>
Cc: Ivan Zhakov <mailto:i...@visualsvn.com>; Subversion Development
<mailto:dev@subversion.apache.org>
Subject: Re: Announcing MaxSVN
On 19/09/2015 16:58, Evgeny Kotkov wrote:
> Stefan Hett <luke1...@gmx.de> writes:
>
>> 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 you
>> presented.
> Thank you :)
So I'm going to stick with the current version numbering layout (since
that's the easiest IMO) but will shift all the version numbers and rely
on the naming of the download files and the changelog to point out which
SVN version builds are based on.
Some examples:
1.7.22.1 -> 1.0.22.1
1.7.22.2 -> 1.0.22.2
1.9.1.1 -> 1.2.1.1 (filename suffixed with -dev-rXXXXX)
1.9.1.2 -> 1.2.1.2
1.10.0.1 -> 1.3.0.1 (filename suffixed with -dev-rXXXXX)
That way there should not be any risk that builds are mistaken for not
yet released SVN versions, everything still works out with the current
MaxSVN build plan and it still preserves the ideas from Bert/Ivan to add
pointers to revision numbers/dev-build-markers in the distribution files.
Regards,
Stefan
