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.
-- Brane
Received on 2015-09-19 22:23:16 CEST