On 19.09.2015 22:43, Stefan wrote:
> On 19/09/2015 22:23, Branko Čibej wrote:
>> On 19.09.2015 22:14, Stefan wrote:
>>> On 19/09/2015 22:00, Johan Corveleyn wrote:
>>>> On Sat, Sep 19, 2015 at 9:44 PM, Stefan <luke1410_at_gmx.de> wrote:
>>>>> 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.
>>>> Sorry, Stefan, but I disagree. You are not in control over where your
>>>> client will end up, who will try it, who will find it googling and
>>>> just click the download button, ...
>>>>
>>>> It's a difficult dilemma: you want to make it clear that it's some
>>>> kind of preview, early-access, ... version of 1.10. But we don't want
>>>> any confusion with the actual 1.10.x. If we would have an official
>>>> "early access program", with somewhat tested preview-releases blessed
>>>> by the project, it would be different (I guess we'd call them
>>>> 1.10.0-alpha1 or -preview1 or -eap1 or -nightly1 or somesuch).
>>>>
>>>> Just another observation: on trunk we already put "1.10.0-dev (under
>>>> development)" as version tag (comes out of 'svn --version' if you
>>>> build from trunk). So it's not like we're not doing something like
>>>> this already. The real 1.10.0 final release will come after all
>>>> 1.10.0-dev builds. So on that grounds, there is some precedent for
>>>> numbering your versions like this (but we've not been spreading those
>>>> builds to a wider audience, setting this version as name of the
>>>> download package ...).
>>> So what is your suggesting then? I doubt that adding a "-dev" suffix
>>> to the version number (which is only recorded in the bugtracker and in
>>> the changelog) would actually solve ur underlying concerns, or would
>>> it? If so, I certainly can do that.
>>>
>>> But I guess the concern lies deeper here and you don't want any
>>> distribution being made available to a wider audience of those
>>> versions which you haven't released yet. Am I reading that correctly
>>> between the lines? If so, I guess there is no point in further
>>> advancing the MaxSVN idea here, because it would basically mean that
>>> it's not adding much to the already existing distributions.
>> What is wrong with the suggestion that you use branch name for
>> unreleased versions, for example, 'maxsvn-trunk-r1704087' or
>> 'maxsvn-1.9.x-r1704087'; but use the whole actual version number for
>> packaged released versions, for example, 'maxsvn-1.9.1-1' or
>> 'maxsvn-1.8.14-2' (with the last number in this case indicating the
>> revision of your package, not the source code it's based on)?
>>
>> I realise that this does not fit well into Microsoft's notion of version
>> numbers as implemented in the VERSIONINFO field of the version resource,
>> but ... lots of stuff doesn't fit well in there.
> Nothing would speak from my side against using that scheme, if that
> would solve all the concerns also the others have.
> I just got the idea that Johan's concern would not be solved by a
> simple switch of the version scheme of the built binaries of MaxSVN.
> If it does, I'll certainly use that one.
>
> From the arguments I read so far on this list I just would not
> understand how this would better solve the concerns than the other
> scheme (I don't have to understand it, if it's suitable in the end ;-)
> as said, whatever concerns any of u have I'll try my best to comply with).
I think Johan explained this quite clearly: whatever version scheme you
use, you should strive not to confuse users into thinking that something
has been release when it has not. Therefore, you can't use anything like
'1.10' because, even though 1.10 "exists" on trunk, it has not been
releaseed and, furthermore, may never be — we could, for some reason or
another, decide to release 1.11 instead.
> Personally I would not choose that version numbering style because
> this is so uncommon in the Windows world (as far as I know) and I
> doubt that anybody besides SVN developers would easily understand it.
> Therefore, I thought this wouldn't be a good style to go with. On the
> other side MaxSVN is aiming primarily for SVN developers/supporters,
> so this should certainly be ok to go with given that audience.
I find that many, many vendors use quite different versioning schemes
than Microsoft; and even they use wildly different schemes for published
product names vs. versions of component names (a good example is Visual
Studio 2015, which is really version 14.0). So there's hardly any common
scheme in the Windows world.
> Just so u get why I personally don't like this:
> I like version numbers where it's obvious from the version itself
> which one comes first and which one is a following/successive one.
> With that style, this won't always work.
>
> Assume there's now (random order to make the point clear):
> maxsvn-trunk-r1704087-1
> maxsvn-1.9.x-r1704598-1
> maxsvn-1.9.15-1
> maxsvn-1.9.x-r1704598-2
> maxsvn-1.10.1-1
> maxsvn-trunk-r1804087-1
>
> which one comes first here? was trunk-r1804087 a version before 1.10
> was released or is it a release of trunk which is after 1.10 was
> branched off?
> What about trunk-r170487-1?
> Where does 1.9.15-1 sort into here?
You can call it 1.9.15-r1704598-1 using the revision in svn_versino.h,
if that helps. Although not that "what comes first" does not have an
unequivocal answer, since we're maintaining parallel release branches
... for example, 1.7.21, 1.8.14 and 1.9.0 all have the exact same
revision number in svn_version.h .. which one comes first? :)
> For SVN development I fully agree that this version scheme makes
> absolute sense and is all fine. But for the sake of a distribution
> this certainly wouldn't be my first choice. :-)
>
> As said, if all of u are fine with using that version scheme for
> MaxSVN I'm going to switch it to that one. Just want to make sure this
> time that it certainly will be ok, so I won't spend another day on
> adjusting the scheme. :-)
At the end of the day, it's your decision what kind of scheme you use.
You can decide to call it "MaxSVN 2015 Collectors Edition with Extra
Bells and Whistles" and not mention the Subversion version number at all. :)
-- Brane
Received on 2015-09-19 23:11:24 CEST