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 <luke1...@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
