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).
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.
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?
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. :-)
Regards,
Stefan
Received on 2015-09-19 22:44:21 CEST