Re: Announcing MaxSVN

[Stefan]

On 24/09/2015 12:35, Bert Huijben wrote:

-Original Message-
From: Ivan Zhakov [mailto:i...@visualsvn.com]
Sent: donderdag 24 september 2015 11:30
To: Daniel Shahaf <d...@daniel.shahaf.name>
Cc: Evgeny Kotkov <evgeny.kot...@visualsvn.com>; Stefan
<luke1...@gmx.de>; Johan Corveleyn <jcor...@gmail.com>; Bert Huijben
<b...@qqmail.nl>; Subversion Development <dev@subversion.apache.org>
Subject: Re: Announcing MaxSVN

On 24 September 2015 at 00:38, Daniel Shahaf <d...@daniel.shahaf.name>
wrote:
[...]

I think it's useful to have the "latest released SVN_VER_PATCH" value in
version number for easier reference.  ("Is 1.7.x-dev-r1700845 before or
after 1.7.22?")  So perhaps:

 tag build:   1.8.14_0
 branch snapshot: 1.8.x-dev-14-r1701565 (where '14' is the latest released
 value of SVN_VER_PATCH)

And in either case, optionally a build number at the end, if Stefan
decides to include that.


Looks like acceptable solution for me.

Sounds like a reasonable format. And I'm going to stick with that one.
If you are determining at any point to change any of the version 
numbering scheme (for instance for trunk), I'll consider adapting to 
that in following releases, even if it would break/change my previous 
version scheme. But I'll think about that when the time arises, given 
that this is most likely still months (if not years) away.

I'm afraid we can discuss this topic forever.

Eventually Stefan has to decide how he wants to create his snapshot builds.

I don't think any of us wants to stop him from producing these builds, but I'm 
afraid adding more and more suggestions will eventually have that effect.


I think Stefan understands our concerns...
I suggest we let him come up with a solution that resolves most of our issues 
and only if there is a real problem with those builds we try to change things.

I'm sure Stefan won't call his builds 'Subversion releases', as he has that 
made clear in almost every of his mails. And as far as I know he isn't even 
looking at releasing production versions.



So let's try resolving this discussion into something actionable, instead of 
just delaying the availability of these binaries.

Perhaps Stefan can then focus on other things... I'm guessing that he will add 
valuable input on (and perhaps patches for) a lot of other features in the 
feature :-)

Thanks for the words Bert.

So the version scheme (which I'll change to today then) will be:

MaxSVN 1.7.22.1 -> MaxSVN 1.7.22-1
MaxSVN 1.7.22.2 -> MaxSVN 1.7.22-2
MaxSVN 1.8.14.1 -> MaxSVN 1.8.14-1
MaxSVN 1.8.15.1 -> MaxSVN 1.8.x-dev-14-r1701565-1
MaxSVN 1.10.0.1 -> MaxSVN trunk-dev-r1697405-1
MaxSVN 1.10.0.2 -> MaxSVN trunk-dev-r1701565-1

The main reason which convinced me for going with a 1.8.x (and trunk) 
version numberings is the intended target audience which are 
people/developers being quite familiar with the SVN source repository 
already and those who want to try out what's on the horizon 
development-wise in SVN.
While the second group (interested people) might not yet be fully 
comfortable with what the version scheme is like, it would certainly not 
hurt them too much to learn that from using MaxSVN and if they decide to 
get closer to the SVN development, they would be already a bit familiar 
with what the 1.8.x-branch is, etc.


I hope to have covered all ur concerns with that scheme (if I oversaw 
something I'll simply have to yet again change it). But since I don't 
know how much time I can invest into that project next week, I guess 
it's better to get that done today and release the versions which 
already are overdue by a week already.


As another outcome of this discussion I also decided to change one small 
(but I guess in your opinion quite important) detail of the MaxSVN 
release cycles.
Originally I planned to release new release-based builds already at the 
time the signing process started (with the idea to give others the 
opportunity to test that release for bugs and inform you of any issues 
they might experience). After all the input from this thread I guess 
it's better (and preferred by most of you) if such a release is done 
after the signing/testing process is done. So that's how I'll do it for 
all future builds.


Last but not least I think I'd be honest with you and not set any false 
expectations. While I'll certainly am planning atm to invest a certain 
amount of my spare time on the SVN project (in addition to the time for 
MaxSVN) and also expect some code patches to come out of this 
contributed time, my current plans are not to fully concentrate on SVN 
alone. I've set some for myself very important priorities for my private 
as well as my professional life in stone already before I started 
MaxSVN, which I'm atm still planning to get done during the next couple 
of months and years. None of this is anything I want to announce 
publicly yet, but I think I should be fair

Re: Announcing MaxSVN

[Ivan Zhakov]

On 24 September 2015 at 00:38, Daniel Shahaf  wrote:
> Evgeny Kotkov wrote on Wed, Sep 23, 2015 at 21:12:19 +0300:
>> Stefan Hett  writes:

[..]

>> So, why not have a scheme that uses tag names when you build from a tag,
>> branch names when you build from a branch, and trunk when you build from 
>> trunk?
>> You could split the builds in two separate groups when presenting to the 
>> user,
>> say, like this:
>>
>>   MaxSVN 1.9.0-1
>>   MaxSVN 1.8.14-1
>>   MaxSVN 1.7.22-1
>>   MaxSVN 1.7.21-1
>>
>>   MaxSVN trunk-dev-r1704854
>>   MaxSVN 1.9.x-dev-r1701565
>>   MaxSVN 1.8.x-dev-r1701493
>>   MaxSVN 1.7.x-dev-r1700845
>>
>
> I think it's useful to have the "latest released SVN_VER_PATCH" value in
> version number for easier reference.  ("Is 1.7.x-dev-r1700845 before or
> after 1.7.22?")  So perhaps:
>
> tag build:   1.8.14_0
> branch snapshot: 1.8.x-dev-14-r1701565 (where '14' is the latest released 
> value of SVN_VER_PATCH)
>
> And in either case, optionally a build number at the end, if Stefan
> decides to include that.
>
Looks like acceptable solution for me.


-- 
Ivan Zhakov

RE: Announcing MaxSVN

[Bert Huijben]

> -Original Message-
> From: Ivan Zhakov [mailto:i...@visualsvn.com]
> Sent: donderdag 24 september 2015 11:30
> To: Daniel Shahaf <d...@daniel.shahaf.name>
> Cc: Evgeny Kotkov <evgeny.kot...@visualsvn.com>; Stefan
> <luke1...@gmx.de>; Johan Corveleyn <jcor...@gmail.com>; Bert Huijben
> <b...@qqmail.nl>; Subversion Development <dev@subversion.apache.org>
> Subject: Re: Announcing MaxSVN
> 
> On 24 September 2015 at 00:38, Daniel Shahaf <d...@daniel.shahaf.name>
> wrote:
> > Evgeny Kotkov wrote on Wed, Sep 23, 2015 at 21:12:19 +0300:
> >> Stefan Hett <luke1...@gmx.de> writes:
> 
> [..]
> 
> >> So, why not have a scheme that uses tag names when you build from a
> tag,
> >> branch names when you build from a branch, and trunk when you build
> from trunk?
> >> You could split the builds in two separate groups when presenting to the
> user,
> >> say, like this:
> >>
> >>   MaxSVN 1.9.0-1
> >>   MaxSVN 1.8.14-1
> >>   MaxSVN 1.7.22-1
> >>   MaxSVN 1.7.21-1
> >>
> >>   MaxSVN trunk-dev-r1704854
> >>   MaxSVN 1.9.x-dev-r1701565
> >>   MaxSVN 1.8.x-dev-r1701493
> >>   MaxSVN 1.7.x-dev-r1700845
> >>
> >
> > I think it's useful to have the "latest released SVN_VER_PATCH" value in
> > version number for easier reference.  ("Is 1.7.x-dev-r1700845 before or
> > after 1.7.22?")  So perhaps:
> >
> > tag build:   1.8.14_0
> > branch snapshot: 1.8.x-dev-14-r1701565 (where '14' is the latest 
> > released
> value of SVN_VER_PATCH)
> >
> > And in either case, optionally a build number at the end, if Stefan
> > decides to include that.
> >
> Looks like acceptable solution for me.

I'm afraid we can discuss this topic forever.

Eventually Stefan has to decide how he wants to create his snapshot builds.

I don't think any of us wants to stop him from producing these builds, but I'm 
afraid adding more and more suggestions will eventually have that effect.


I think Stefan understands our concerns...
I suggest we let him come up with a solution that resolves most of our issues 
and only if there is a real problem with those builds we try to change things.

I'm sure Stefan won't call his builds 'Subversion releases', as he has that 
made clear in almost every of his mails. And as far as I know he isn't even 
looking at releasing production versions.



So let's try resolving this discussion into something actionable, instead of 
just delaying the availability of these binaries.

Perhaps Stefan can then focus on other things... I'm guessing that he will add 
valuable input on (and perhaps patches for) a lot of other features in the 
feature :-)

Bert

Re: Announcing MaxSVN

[Stefan]

On 21/09/2015 23:10, Daniel Shahaf wrote:

Johan Corveleyn wrote on Sun, Sep 20, 2015 at 00:00:42 +0200:

On Sat, Sep 19, 2015 at 11:35 PM, Stefan  wrote:

On 19/09/2015 22:48, Johan Corveleyn wrote:

On Sat, Sep 19, 2015 at 10:14 PM, Stefan  wrote:

I was just trying to say that we've already had "1.10.0-dev" in our
own "version tag" (ever since branching 1.9.x), but that we've never
had to think about this because we weren't distributing it. You've put
us in a new situation, but that's not a bad thing :-). How to name the
binary package that you're putting up for download ... without
creating confusion.

So the suggestion would be to use the scheme based on Branko's, Bert's,
Ivan's and Evgeny's suggestions:
MaxSVN 1.7.22.1 -> MaxSVN 1.7.22-1
MaxSVN 1.7.22.2 -> MaxSVN 1.7.22-2
MaxSVN 1.8.14.1 -> MaxSVN 1.8.14-1
MaxSVN 1.8.15.1 -> MaxSVN 1.8.x-dev-r1701493-1
MaxSVN 1.10.0.1 -> MaxSVN trunk-dev-r1697405-1
MaxSVN 1.10.0.2 -> MaxSVN trunk-dev-r1701565-1

Would that cover ur concerns you raised too?

Yes, I think so (but I can't speak for the others of course).

Putting my user-hat back on, I can see that it can be a tad annoying
that you can't see at a glance that 1.8.x-dev-r1701493-1 is pre or
post 1.8.14-1, but I guess that can be solved best by describing it on
the web-page (and maybe with help of ordering given on your website).

To address this, how about 1.8.14_42-XXX, where:

- 1.8.14 is the upstream release that MaxSVN release is a superset of,
   i.e., typically "%d.%d.%d" % (SVN_VER_MAJOR, SVN_VER_MINOR, SVN_VER_PATCH-1);

- 42 is the number of commits to the 1.8.x branch between 1.8.14's magic
   revision and the revision the MaxSVN release is based on (so a build
   of the 1.8.14 tag would be 1.8.14_0-XXX);

- XXX is a build identifier.

This will work for stable branches, but I'm not sure what to do about
trunk.  In trunk, the issue has nothing to do with Stefan's packaging:
the trunk tree self-describes as being SVN_VER_MINOR=10, but it might
not be compatible with 1.10 GA.  I don't think there's a clean way
around that short of adopting the "even == stable, odd == unstable"
SVN_VER_MINOR convention that some projects use.

We could do that tomorrow, really.  We'd just have to skip 1.10 and make
trunk 1.11, and the next release after 1.9 will be 1.12, which would be
odd — sorry, I meant to say "unusual" — but if it has a tangible benefit
in the form of reducing user confusion, it might be worthwhile.
To be honest, when looking at 1.8.14_42 alone, it won't immediately pop 
into my mind that this is a version newer than 1.8.14 (I'd think it's 
some special build of the 1.8.14 source).
Changing that to 1.8.14.42 (or .1 or whatever magic number to be used) 
would work better, but then might mislead users in thinking that this is 
an official SVN version (aka: 1.8.14.1) rather than some development 
build I guess.


Considering the pros and cons of my previous and ur suggested scheme, I 
think I'd prefer the 1.8.14_42-x style regardless, because it seems to 
be the best compromise between all the different options.


I'm feeling a bit honored here that you are even talking about 
considering the option to change ur version numbering for trunk in the 
light to make that solve my conflict with naming trunk-based builds. If 
in the end it's decided to be changed, I would certainly adapt to that 
version scheme for MaxSVN as well.


Until that point, using "MaxSVN trunk-dev-r1701565-1"-style versions for 
trunk builds is fine and I can swap this at any point without having to 
change the previously released trunk versions.


So unless some new arguments will influence my mind again, this is the 
version scheme I'd aim for:

(magic numbers are temporary, I didn't quite check them yet)
MaxSVN 1.7.22.1 -> MaxSVN 1.7.22_0-1
MaxSVN 1.7.22.2 -> MaxSVN 1.7.22_0-2
MaxSVN 1.8.14.1 -> MaxSVN 1.8.14_0-1
MaxSVN 1.8.15.1 -> MaxSVN 1.8.14_42-1
MaxSVN 1.10.0.1 -> MaxSVN trunk-dev-r1697405-1
MaxSVN 1.10.0.2 -> MaxSVN trunk-dev-r1701565-1

Regards,
Stefan

Re: Announcing MaxSVN

[Daniel Shahaf]

Evgeny Kotkov wrote on Wed, Sep 23, 2015 at 21:12:19 +0300:
> Stefan Hett  writes:
> 
> > So unless some new arguments will influence my mind again, this is the
> > version scheme I'd aim for:
> > (magic numbers are temporary, I didn't quite check them yet)
> >
> > MaxSVN 1.7.22.1 -> MaxSVN 1.7.22_0-1
> > MaxSVN 1.7.22.2 -> MaxSVN 1.7.22_0-2
> > MaxSVN 1.8.14.1 -> MaxSVN 1.8.14_0-1
> > MaxSVN 1.8.15.1 -> MaxSVN 1.8.14_42-1
> > MaxSVN 1.10.0.1 -> MaxSVN trunk-dev-r1697405-1
> > MaxSVN 1.10.0.2 -> MaxSVN trunk-dev-r1701565-1
> 
> I am thinking that 1.8.14_42-1 could be err..., surprising.
> 
> Here is what it looks like if I try to put myself in the users' shoes.
> I am looking for Subversion 1.8, and I would love it to work without problems.
> At some point I stumble across MaxSVN, and here is what I see:
> 
>   MaxSVN 1.8.14_0-1
>   MaxSVN 1.8.14_42-1
> 
> Perhaps, I could also see this, depending on how the versions are sorted:
> 
>   MaxSVN 1.8.14_42-1
>   MaxSVN 1.8.14_0-1
> 
> "The bigger the number the better the build, right?", I say to myself and
> start downloading MaxSVN 1.8.14_42-1.  Well, wrong, because it is based
> on a snapshot of the branch and not on the released version.
> 

1.8.14_42 is just 1.8.14_0 plus some backports.  Assuming that one of
the backports has a bug, if we don't catch the bug within a week of
making the backport, chances are 50/50 whether we'll catch the bug
before or after we cut the 1.8.15.¹  So, practically speaking, I would
think a 1.8.14_42 that is over a week old is as stable as 1.8.15 will
be, when it's released.

The problem with snapshots isn't stability, then; it's that they aren't
covered by compatibility promises.  _If_ an on-disk-format bug creeps
into 1.8.14_42 and gets fixed before 1.8.15_0, there might not be an
upgrade path from that 1.8.14_42 snapshot to anything newer or older:
https://subversion.apache.org/docs/community-guide/releasing#prerelease-caveats

So I think you're right: _0 and _42 are fundamentally different, and it
would be good to communicate this difference to users.  The most
straightforward way to do this would be to include SVN_VER_NUMTAG in the
version number.

¹ That's just a ballpark estimate.

> So, why not have a scheme that uses tag names when you build from a tag,
> branch names when you build from a branch, and trunk when you build from 
> trunk?
> You could split the builds in two separate groups when presenting to the user,
> say, like this:
> 
>   MaxSVN 1.9.0-1
>   MaxSVN 1.8.14-1
>   MaxSVN 1.7.22-1
>   MaxSVN 1.7.21-1
> 
>   MaxSVN trunk-dev-r1704854
>   MaxSVN 1.9.x-dev-r1701565
>   MaxSVN 1.8.x-dev-r1701493
>   MaxSVN 1.7.x-dev-r1700845
> 

I think it's useful to have the "latest released SVN_VER_PATCH" value in
version number for easier reference.  ("Is 1.7.x-dev-r1700845 before or
after 1.7.22?")  So perhaps:

tag build:   1.8.14_0
branch snapshot: 1.8.x-dev-14-r1701565 (where '14' is the latest released 
value of SVN_VER_PATCH)

And in either case, optionally a build number at the end, if Stefan
decides to include that.

Cheers,

Daniel

> Worth mentioning, I am not that sure about the necessity of having different
> builds (like 1.9.0-1 and 1.9.0-2) based on the same source.  You could 
> probably
> get rid of them by only using new dependencies for new builds.
> 
> In other words, when you build MaxSVN 1.9.0 and upload it, it is immutable.
> You could then update APR version in MaxSVN 1.9.1, if you feel like it.  Doing
> so would turn the scheme into something fairly common and easy to understand:
> 
>   MaxSVN 1.9.0
>   MaxSVN 1.8.14
>   MaxSVN 1.7.22
>   MaxSVN 1.7.21
> 
>   MaxSVN trunk-dev-r1704854
>   MaxSVN 1.9.x-dev-r1701565
>   MaxSVN 1.8.x-dev-r1701493
>   MaxSVN 1.7.x-dev-r1700845
> 
> 
> Regards,
> Evgeny Kotkov

Re: Announcing MaxSVN

[Daniel Shahaf]

Johan Corveleyn wrote on Sun, Sep 20, 2015 at 00:00:42 +0200:
> On Sat, Sep 19, 2015 at 11:35 PM, Stefan  wrote:
> > On 19/09/2015 22:48, Johan Corveleyn wrote:
> >>
> >> On Sat, Sep 19, 2015 at 10:14 PM, Stefan  wrote:
> >>>
> >>> On 19/09/2015 22:00, Johan Corveleyn wrote:
> >>
> >> ...
> >>>
> >>> 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.
> >>
> >> No, that's not what I meant at all. Stop reading between the lines
> >> :-). I like your efforts to bring early builds to a wider (developer /
> >> expert / ...) audience. I think it's a good thing.
> >
> > ;-) - so gonna try to stop that habit (aka: reading between lines), but no
> > promises I succeed
> >>
> >> I was just trying to say that we've already had "1.10.0-dev" in our
> >> own "version tag" (ever since branching 1.9.x), but that we've never
> >> had to think about this because we weren't distributing it. You've put
> >> us in a new situation, but that's not a bad thing :-). How to name the
> >> binary package that you're putting up for download ... without
> >> creating confusion.
> >
> > So the suggestion would be to use the scheme based on Branko's, Bert's,
> > Ivan's and Evgeny's suggestions:
> > MaxSVN 1.7.22.1 -> MaxSVN 1.7.22-1
> > MaxSVN 1.7.22.2 -> MaxSVN 1.7.22-2
> > MaxSVN 1.8.14.1 -> MaxSVN 1.8.14-1
> > MaxSVN 1.8.15.1 -> MaxSVN 1.8.x-dev-r1701493-1
> > MaxSVN 1.10.0.1 -> MaxSVN trunk-dev-r1697405-1
> > MaxSVN 1.10.0.2 -> MaxSVN trunk-dev-r1701565-1
> >
> > Would that cover ur concerns you raised too?
> 
> Yes, I think so (but I can't speak for the others of course).
> 
> Putting my user-hat back on, I can see that it can be a tad annoying
> that you can't see at a glance that 1.8.x-dev-r1701493-1 is pre or
> post 1.8.14-1, but I guess that can be solved best by describing it on
> the web-page (and maybe with help of ordering given on your website).

To address this, how about 1.8.14_42-XXX, where:

- 1.8.14 is the upstream release that MaxSVN release is a superset of,
  i.e., typically "%d.%d.%d" % (SVN_VER_MAJOR, SVN_VER_MINOR, SVN_VER_PATCH-1);

- 42 is the number of commits to the 1.8.x branch between 1.8.14's magic
  revision and the revision the MaxSVN release is based on (so a build
  of the 1.8.14 tag would be 1.8.14_0-XXX);

- XXX is a build identifier.

This will work for stable branches, but I'm not sure what to do about
trunk.  In trunk, the issue has nothing to do with Stefan's packaging:
the trunk tree self-describes as being SVN_VER_MINOR=10, but it might
not be compatible with 1.10 GA.  I don't think there's a clean way
around that short of adopting the "even == stable, odd == unstable"
SVN_VER_MINOR convention that some projects use.

We could do that tomorrow, really.  We'd just have to skip 1.10 and make
trunk 1.11, and the next release after 1.9 will be 1.12, which would be
odd — sorry, I meant to say "unusual" — but if it has a tangible benefit
in the form of reducing user confusion, it might be worthwhile.

Cheers,

Daniel

  


> BTW, thanks for doing this, I think it's very useful work (especially
> since building SVN on Windows is so hard). And thanks for your
> patience in talking these details through with the dev community.

Re: Announcing MaxSVN

[Stefan]

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  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-r.

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 

Re: Announcing MaxSVN

[Branko Čibej]

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  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-r.
>
> 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 

Re: Announcing MaxSVN

[Stefan]

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-r.

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-rX)
1.9.1.2 -> 1.2.1.2
1.10.0.1 -> 1.3.0.1 (filename suffixed with -dev-rX)

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

Re: Announcing MaxSVN

[Stefan]

On 19/09/2015 23:11, Branko Čibej wrote:

On 19.09.2015 22:43, Stefan wrote:

On 19/09/2015 22:23, Branko Čibej wrote:
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.
This is completely clear to me and was why I thought that untangling the 
version scheme from SVN's one by starting with 1.0-1.3 for the SVN 
1.7-trunk releases would solve that concern.



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.
The case of VS 2015 is that a product name differs from its actual 
version number. This is not too uncommon. But when it comes to version 
numbering I really have a hard time finding examples which are quite 
common in the Linux world (like the Debian patch-versions/-builds, etc.).

Anyway, this is a different story. :-)



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? :)
Well, logically you would order all 1.7.x before any 1.8 version. By 
"what comes first" I was merely speaking feature/logical/version wise, 
not necessarily time-wise. This is quite clear for the x.y.z format, but 
not that much for the 1.9.x vs. 1.9.15 vs. trunk format.



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. :)


I like the name. Maybe I'd pick that then? :-)

Leaving the joking behind:
So to keep things simple and stop wasting more of our time on that 
matter, this is the current suggestion (based on the original version 
scheme):

MaxSVN 1.7.22.1 -> MaxSVN 1.7.22-1
MaxSVN 1.7.22.2 -> MaxSVN 1.7.22-2
MaxSVN 1.8.14.1 -> MaxSVN 1.8.14-1
MaxSVN 1.8.15.1 -> MaxSVN 1.8.x-dev-r1701493-1
MaxSVN 1.10.0.1 -> MaxSVN trunk-dev-r1697405-1
MaxSVN 1.10.0.2 -> MaxSVN trunk-dev-r1701565-1

Filenames will be named exactly like the version number scheme aka: 
maxsvn_1.8.x-dev-r1701493-1.zip


I'll wait at least till Friday next week to give everybody some time to 
raise his concern and/or state his opinion on it. Afterwards I'll adjust 
the few existing releases to match the updated version scheme.


Regards,

RE: Announcing MaxSVN

[Bert Huijben]

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

-Original Message-
From: "Stefan" <luke1...@gmx.de>
Sent: ‎19-‎9-‎2015 18:12
To: "Evgeny Kotkov" <evgeny.kot...@visualsvn.com>
Cc: "Ivan Zhakov" <i...@visualsvn.com>; "Subversion Development" 
<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-rX)
1.9.1.2 -> 1.2.1.2
1.10.0.1 -> 1.3.0.1 (filename suffixed with -dev-rX)

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

Re: Announcing MaxSVN

[Stefan]

On 19/09/2015 22:48, Johan Corveleyn wrote:

On Sat, Sep 19, 2015 at 10:14 PM, Stefan  wrote:

On 19/09/2015 22:00, Johan Corveleyn wrote:

...

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.

No, that's not what I meant at all. Stop reading between the lines
:-). I like your efforts to bring early builds to a wider (developer /
expert / ...) audience. I think it's a good thing.
;-) - so gonna try to stop that habit (aka: reading between lines), but 
no promises I succeed

I was just trying to say that we've already had "1.10.0-dev" in our
own "version tag" (ever since branching 1.9.x), but that we've never
had to think about this because we weren't distributing it. You've put
us in a new situation, but that's not a bad thing :-). How to name the
binary package that you're putting up for download ... without
creating confusion.
So the suggestion would be to use the scheme based on Branko's, Bert's, 
Ivan's and Evgeny's suggestions:

MaxSVN 1.7.22.1 -> MaxSVN 1.7.22-1
MaxSVN 1.7.22.2 -> MaxSVN 1.7.22-2
MaxSVN 1.8.14.1 -> MaxSVN 1.8.14-1
MaxSVN 1.8.15.1 -> MaxSVN 1.8.x-dev-r1701493-1
MaxSVN 1.10.0.1 -> MaxSVN trunk-dev-r1697405-1
MaxSVN 1.10.0.2 -> MaxSVN trunk-dev-r1701565-1

Would that cover ur concerns you raised too?

Regards,
Stefan

Re: Announcing MaxSVN

[Johan Corveleyn]

On Sat, Sep 19, 2015 at 9:44 PM, Stefan  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-r.
>
> 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 ...).

-- 
Johan

Re: Announcing MaxSVN

[Stefan]

On 19/09/2015 22:00, Johan Corveleyn wrote:

On Sat, Sep 19, 2015 at 9:44 PM, Stefan  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-r.

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.


Regards,
Stefan

Re: Announcing MaxSVN

[Stefan]

First of all thanks for ur input and time Evgeny.

Stefan Hett  writes:


What would u say about this other scheme:
1.9.1.1 -> 1.9.1-1-r1694136-dev
1.9.1.2 -> 1.9.1-2
1.9.2.1 -> 1.9.2-1-r1701493-dev

i.e. 1.9.1.2 is a tag-based build on the 1.9.1 branch (therefore it won't
suffix the revision number and dev suffix).

Given that change, I'm even thinking whether the -dev suffix is still
required in the version number or whether it can be dropped completely as
in:
1.9.1.1 -> 1.9.1-1-r1694136
1.9.1.2 -> 1.9.1-2
1.9.2.1 -> 1.9.2-1-r1701493

Any thoughts would be very much appreciated.

I'd say that both of this variants still are quite misleading.  A version
cannot refer to something that *does not yet exist*.
My thinking here (from the point of MaxSVN) would be that while the 
final version doesn't exist yet, the work towards that version certainly 
already exists. But I also see ur point, of course.

1.9.2-1-r1701493 actually means "Subversion 1.9.2 + my custom label".  This
is misleading, because Subversion 1.9.2 doesn't exist at this point of time.
Moreover, there are situations when a certain patch release is skipped, e.g.,
Subversion 1.8.12 was not released [1], so it's incorrect to label something
with the "expected next version".  The same applies to 1.10.0-1-... builds
that could be misinterpreted as the actual 1.10 builds, while they are just
built from /trunk.
For the case of a skipped SVN version, the result in MaxSVN's current 
version scheme would be that following

1.8.12.x would be 1.8.13.1
With the addition of (let's say a -dev suffix for dev built versions) 
that would be:
1.8.12.x-dev would follow 1.8.13.1 (i.e. there would not be a 1.8.12.x 
version without the -dev suffix in the 1.8.12.x release chain.



So, the version should not contain something like "1.9.2" unless 1.9.2 is an
existing official release.

Here is what I can suggest:

- MaxSVN-1.9.1-x64
   (a binary package of Subversion 1.9.1 from /tags/1.9.1)

- MaxSVN-1.9.x-dev-r1701493-x64
   (a development build built from /branches/1.9.x@r1701493)

- MaxSVN-trunk-dev-r1701493-x64
   (a development build built from /trunk@r1701493)

[1] https://archive.apache.org/dist/subversion/
Problem with this scheme is that it won't produce different version 
numbers for new MaxSVN releases if these are based on the same 
revision/version of SVN.
This is quite the norm of MaxSVN, because there will be builds for 
instance for 1.7.22 whenever one of the dependencies (let's say APR) 
gets updated. A simple MaxSVN-1.7.22-x64 won't work here, since that one 
was already released.


The same problem applies to dev-builds (if the revision number doesn't 
change).
For trunk builds it's not obvious to the user from the version number 
alone which development chain this one is based on when new major 
releases are tagged (aka: is it a version before 1.9 or is it one 
already on the way towards 1.10 after 1.9 was released).


I'd imagine the following style could work (it's related to the version 
numbering from Visual Assist X (from Wholetomato)):

- MaxSVN-1.9.1-x64 (build 1)
- MaxSVN-1.9.2-dev-r1701493-x64 (build 1)
- MaxSVN-1.10.0-dev-r1701493-x64 (build 1)

Whenever there'd be another release of MaxSVN without the underlying SVN 
source changing, the build counter would increase, while the rest stays 
the same.
But to me this looks even more complicated than the previously suggested 
style.


I also prefer to keep the version part determining the logical order of 
releases at the beginning of the version number, so it's easier to get 
the incremental order right.


Guess I've to think a bit more about that one, but most likely will go 
with a combination of ur and Ivan's suggestion and my originally 
proposed scheme.


Further input is more than welcome.

Regards,
Stefan

Re: Announcing MaxSVN

[Stefan]

On 19/09/2015 16:43, Evgeny Kotkov wrote:

Stefan Hett  writes:


I'd imagine the following style could work (it's related to the version
numbering from Visual Assist X (from Wholetomato)):
- MaxSVN-1.9.1-x64 (build 1)
- MaxSVN-1.9.2-dev-r1701493-x64 (build 1)
- MaxSVN-1.10.0-dev-r1701493-x64 (build 1)

Let me try to rephrase myself — I don't think that the exact details of the
versioning scheme are that important.  What is important, however, is whether
the scheme uses or doesn't use non-existing versions of Subversion in it.

For instance, "MaxSVN-1.9.2-something" contains version 1.9.2 that doesn't
exist.  "MaxSVN-1.10.0-something" contains version 1.10.0 that also doesn't
exist.  These versions are based on two arbitrary states of /branches/1.9.x
and /trunk, respectively, but they also are indexed by the search robots and
have a chance of showing up in the results for a person who is looking for
Subversion 1.9.2 or, at some point, for Subversion 1.10.

We could have people misinterpreting these versions and telling us: "So, I
downloaded Subversion 1.10, and it corrupted my data", even though there is
no Subversion 1.10 yet, and they were just using the /trunk build labeled as
1.10.  And there is not much that can be done at this point.

I think that you can choose any scheme that works best for you and is suitable
for your workflow, but could you please ensure that binary packages that you
publish do not include the versions of Subversion that don't exist at the
moment?

Thanks.
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.


Regards,
Stefan

Re: Announcing MaxSVN

[Evgeny Kotkov]

Stefan Hett  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 :)


Regards,
Evgeny Kotkov

Re: Announcing MaxSVN

[Evgeny Kotkov]

Stefan Hett  writes:

> I'd imagine the following style could work (it's related to the version
> numbering from Visual Assist X (from Wholetomato)):
> - MaxSVN-1.9.1-x64 (build 1)
> - MaxSVN-1.9.2-dev-r1701493-x64 (build 1)
> - MaxSVN-1.10.0-dev-r1701493-x64 (build 1)

Let me try to rephrase myself — I don't think that the exact details of the
versioning scheme are that important.  What is important, however, is whether
the scheme uses or doesn't use non-existing versions of Subversion in it.

For instance, "MaxSVN-1.9.2-something" contains version 1.9.2 that doesn't
exist.  "MaxSVN-1.10.0-something" contains version 1.10.0 that also doesn't
exist.  These versions are based on two arbitrary states of /branches/1.9.x
and /trunk, respectively, but they also are indexed by the search robots and
have a chance of showing up in the results for a person who is looking for
Subversion 1.9.2 or, at some point, for Subversion 1.10.

We could have people misinterpreting these versions and telling us: "So, I
downloaded Subversion 1.10, and it corrupted my data", even though there is
no Subversion 1.10 yet, and they were just using the /trunk build labeled as
1.10.  And there is not much that can be done at this point.

I think that you can choose any scheme that works best for you and is suitable
for your workflow, but could you please ensure that binary packages that you
publish do not include the versions of Subversion that don't exist at the
moment?

Thanks.


Regards,
Evgeny Kotkov

Re: Announcing MaxSVN

[Stefan]

On 19/09/2015 18:12, Stefan wrote:

On 19/09/2015 16:58, Evgeny Kotkov wrote:

Stefan Hett  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-rX)
1.9.1.2 -> 1.2.1.2
1.10.0.1 -> 1.3.0.1 (filename suffixed with -dev-rX)

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.
For reference: The change of the version numbering scheme is tracked in 
MaxSVN's bugtracker under: http://www.luke1410.de:8090/browse/MAXSVN-11


Regards,
Stefan

Re: Announcing MaxSVN

[Stefan]

On 19/09/2015 16:58, Evgeny Kotkov wrote:

Stefan Hett  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-rX)
1.9.1.2 -> 1.2.1.2
1.10.0.1 -> 1.3.0.1 (filename suffixed with -dev-rX)

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

Re: Announcing MaxSVN

[Ivan Zhakov]

On 13 September 2015 at 23:52, Stefan  wrote:
> Hi Ivan,
>
Hi Stefan!

>> On 7 September 2015 at 18:47, Stefan  wrote:
>>>
>>> Hi,
>>>
>>> I'm pleased to announce the availability of a new distribution of SVN
>>> called: "MaxSVN".
>>> In contrast to other SVN distributions this one is a bit different since
>>> it
>>> aims towards being used primarily to support SVN development rather than
>>> being used in production environments.
>>>
>>> Its primary purpose is to test and identify issues of SVN against the
>>> latest
>>> build tools and dependencies on Windows.
>>>
>>> It can however also be useful in other situations like if you wanna check
>>> whether a current development branch solved a particular issue or to
>>> check
>>> out the new features in an upcoming SVN release before it becomes
>>> available
>>> as part of a final release.
>>>
>>> Please note once more that I strongly suggest against using MaxSVN in
>>> your
>>> daily productive use. Please stick with one of the already available
>>> Windows
>>> distributions. A list of these can be found on the MaxSVN webpage:
>>> http://www.luke1410.de/typo3/index.php?id=97
>>>
>>> Also understand that MaxSVN is a product distributed, maintained and
>>> created
>>> by myself and is not directly associated with the Apache Subversion
>>> project.
>>>
>>> The latest current available builds are:
>>> - 1.7.22.2 (current latest 1.7 released version)
>>> - 1.8.14.2 (current latest 1.8 released version)
>>> - 1.8.15.1 (current 1.8 preview version)
>>> - 1.9.1.2 (current latest 1.9 released version)
>>> - 1.9.2.1 (current 1.9 preview version)
>>> - 1.10.0.2 (current 1.10 preview version)
>>>
>>> Feel free to send any feedback directly to me by mail or use the
>>> bugtracker
>>> at http://www.luke1410.de:8090/browse/MAXSVN to add bugreports/feature
>>> requests.
>>>
>> May I suggest to rename branch and trunk builds version to something
>> like 1.9.x-dev-r and 1.10.x-dev-rXXX? Never replace 'x' with the
>> current version patch version. I.e. '1.9.x-dev-r1701757'.
>>
>> Because versions like 1.9.2.1 may confuse users. It's very hard to
>> find difference between 1.9.1.2 and 1.9.2.1 to distinguish official
>> releases from development builds.
>>
>> Thanks!
>
> I agree with u that the version numbering is not too clear and I also tend
> to agree that adding the revision number to the version number makes sense
> given the target audience of MaxSVN.
>
> If I understand u right, then u are suggesting not to use SVN's patch
> version in MaxSVN version numbering scheme. I thought having that directly
> in the version number available would actually benefit users, because they
> would directly see which SVN version a MaxSVN version is based on.
>
You are understand my correctly. My point that you cannot call
something build from 1.9.x branch as 1.9.1 or 1.9.2. The only build
from official distribution or tag should have patch version in version
number IMO. For example at which point you're going to change patch
version of branch builds? We change it at arbitrary time: sometimes
it's done immediately after creating, sometimes later.

> I also think that Bert's suggestion to use the "dev" marker for versions
> which are based on a not-yet released build is quite good and drop that
> marker once a build is based on a released version.
>
> What's ur opinion on using the following scheme instead:
> 1.9.x-y-rxxx-dev for versions not yet released
> 1.9.x-y-rxxx for versions based on SVN versions which are already released
>
> x is the current minor version of the SVN version
> y is a running number for MaxSVN builds
> rxxx is the SVN revision a build is based on
>
> So in case of the current 1.9 MaxSVN releases this is how with the other
> scheme things would look like:
> 1.9.0.1 -> 1.9.0-1-r1692833
What is the reason to include revision number for tag builds? In this
case you reduce difference between tag and branch builds, which may
increase user confusion. IMO tag and branch builds should be very
distinguishable from each other.

> 1.9.1.1 -> 1.9.1-1-r1694136-dev
> 1.9.1.2 -> 1.9.1-2-r1698174
> 1.9.2.1 -> 1.9.2-1-r1701493-dev
>
I find proposed scheme very confusing for users. It already confused
users on tsvn-users list: they have an impression that 1.9.2 is
already released, because they noticed 1.9.2-something builds on your
website.

-- 
Ivan Zhakov

Re: Announcing MaxSVN

[Stefan]

Hi Ivan,

On 7 September 2015 at 18:47, Stefan  wrote:

Hi,

I'm pleased to announce the availability of a new distribution of SVN
called: "MaxSVN".
In contrast to other SVN distributions this one is a bit different since
it
aims towards being used primarily to support SVN development rather than
being used in production environments.

Its primary purpose is to test and identify issues of SVN against the
latest
build tools and dependencies on Windows.

It can however also be useful in other situations like if you wanna check
whether a current development branch solved a particular issue or to
check
out the new features in an upcoming SVN release before it becomes
available
as part of a final release.

Please note once more that I strongly suggest against using MaxSVN in
your
daily productive use. Please stick with one of the already available
Windows
distributions. A list of these can be found on the MaxSVN webpage:
http://www.luke1410.de/typo3/index.php?id=97

Also understand that MaxSVN is a product distributed, maintained and
created
by myself and is not directly associated with the Apache Subversion
project.

The latest current available builds are:
- 1.7.22.2 (current latest 1.7 released version)
- 1.8.14.2 (current latest 1.8 released version)
- 1.8.15.1 (current 1.8 preview version)
- 1.9.1.2 (current latest 1.9 released version)
- 1.9.2.1 (current 1.9 preview version)
- 1.10.0.2 (current 1.10 preview version)

Feel free to send any feedback directly to me by mail or use the
bugtracker
at http://www.luke1410.de:8090/browse/MAXSVN to add bugreports/feature
requests.


May I suggest to rename branch and trunk builds version to something
like 1.9.x-dev-r and 1.10.x-dev-rXXX? Never replace 'x' with the
current version patch version. I.e. '1.9.x-dev-r1701757'.

Because versions like 1.9.2.1 may confuse users. It's very hard to
find difference between 1.9.1.2 and 1.9.2.1 to distinguish official
releases from development builds.

Thanks!

I agree with u that the version numbering is not too clear and I also tend
to agree that adding the revision number to the version number makes sense
given the target audience of MaxSVN.

If I understand u right, then u are suggesting not to use SVN's patch
version in MaxSVN version numbering scheme. I thought having that directly
in the version number available would actually benefit users, because they
would directly see which SVN version a MaxSVN version is based on.


You are understand my correctly. My point that you cannot call
something build from 1.9.x branch as 1.9.1 or 1.9.2. The only build
from official distribution or tag should have patch version in version
number IMO. For example at which point you're going to change patch
version of branch builds? We change it at arbitrary time: sometimes
it's done immediately after creating, sometimes later.
My current process is that once a tag-version becomes available (let's 
say 1.9.2), the next build from the branch would increase the patch 
number in MaxSVN (in case of 1.9.2 being released, the next 
1.9-branch-based build would be 1.9.3.1 (in the current scheme)).
Reasoning for this choice is that the development is on the path to a 
following 1.9.3 release and all MaxSVN builds on that path to that 
version are represented with that (potentially) targeted next version 
number (aka 1.9.3.x).
I understand the current SVN release process includes a version bump on 
the branch at the point a new version is tagged, is that wrong?
Since MaxSVN won't make builds of branches which (code wise) match 
tagged versions (i.e. 1.9.3.1 would not be build for as long as the 
1.9-branch equals the 1.9.2-tag), there should not be much an issue 
here. Or am I missing something?

I also think that Bert's suggestion to use the "dev" marker for versions
which are based on a not-yet released build is quite good and drop that
marker once a build is based on a released version.

What's ur opinion on using the following scheme instead:
1.9.x-y-rxxx-dev for versions not yet released
1.9.x-y-rxxx for versions based on SVN versions which are already released

x is the current minor version of the SVN version
y is a running number for MaxSVN builds
rxxx is the SVN revision a build is based on

So in case of the current 1.9 MaxSVN releases this is how with the other
scheme things would look like:
1.9.0.1 -> 1.9.0-1-r1692833

What is the reason to include revision number for tag builds? In this
case you reduce difference between tag and branch builds, which may
increase user confusion. IMO tag and branch builds should be very
distinguishable from each other.
Good question. I didn't put too much thought into that one. Just went 
with consistency. But I agree that dropping the revision number for 
tag-based-builds would make it more obvious to the user which version is 
a dev-based and which one is a released-based version.

1.9.1.1 -> 1.9.1-1-r1694136-dev
1.9.1.2 -> 1.9.1-2-r1698174
1.9.2.1 -> 1.9.2-1-r1701493-dev


I find 

Re: Announcing MaxSVN

[Evgeny Kotkov]

Stefan Hett  writes:

> What would u say about this other scheme:
> 1.9.1.1 -> 1.9.1-1-r1694136-dev
> 1.9.1.2 -> 1.9.1-2
> 1.9.2.1 -> 1.9.2-1-r1701493-dev
>
> i.e. 1.9.1.2 is a tag-based build on the 1.9.1 branch (therefore it won't
> suffix the revision number and dev suffix).
>
> Given that change, I'm even thinking whether the -dev suffix is still
> required in the version number or whether it can be dropped completely as
> in:
> 1.9.1.1 -> 1.9.1-1-r1694136
> 1.9.1.2 -> 1.9.1-2
> 1.9.2.1 -> 1.9.2-1-r1701493
>
> Any thoughts would be very much appreciated.

I'd say that both of this variants still are quite misleading.  A version
cannot refer to something that *does not yet exist*.

1.9.2-1-r1701493 actually means "Subversion 1.9.2 + my custom label".  This
is misleading, because Subversion 1.9.2 doesn't exist at this point of time.
Moreover, there are situations when a certain patch release is skipped, e.g.,
Subversion 1.8.12 was not released [1], so it's incorrect to label something
with the "expected next version".  The same applies to 1.10.0-1-... builds
that could be misinterpreted as the actual 1.10 builds, while they are just
built from /trunk.

So, the version should not contain something like "1.9.2" unless 1.9.2 is an
existing official release.

Here is what I can suggest:

- MaxSVN-1.9.1-x64
  (a binary package of Subversion 1.9.1 from /tags/1.9.1)

- MaxSVN-1.9.x-dev-r1701493-x64
  (a development build built from /branches/1.9.x@r1701493)

- MaxSVN-trunk-dev-r1701493-x64
  (a development build built from /trunk@r1701493)

[1] https://archive.apache.org/dist/subversion/


Regards,
Evgeny Kotkov

Re: Announcing MaxSVN

[Stefan]

Hi Ivan,

On 7 September 2015 at 18:47, Stefan  wrote:

Hi,

I'm pleased to announce the availability of a new distribution of SVN
called: "MaxSVN".
In contrast to other SVN distributions this one is a bit different since it
aims towards being used primarily to support SVN development rather than
being used in production environments.

Its primary purpose is to test and identify issues of SVN against the latest
build tools and dependencies on Windows.

It can however also be useful in other situations like if you wanna check
whether a current development branch solved a particular issue or to check
out the new features in an upcoming SVN release before it becomes available
as part of a final release.

Please note once more that I strongly suggest against using MaxSVN in your
daily productive use. Please stick with one of the already available Windows
distributions. A list of these can be found on the MaxSVN webpage:
http://www.luke1410.de/typo3/index.php?id=97

Also understand that MaxSVN is a product distributed, maintained and created
by myself and is not directly associated with the Apache Subversion project.

The latest current available builds are:
- 1.7.22.2 (current latest 1.7 released version)
- 1.8.14.2 (current latest 1.8 released version)
- 1.8.15.1 (current 1.8 preview version)
- 1.9.1.2 (current latest 1.9 released version)
- 1.9.2.1 (current 1.9 preview version)
- 1.10.0.2 (current 1.10 preview version)

Feel free to send any feedback directly to me by mail or use the bugtracker
at http://www.luke1410.de:8090/browse/MAXSVN to add bugreports/feature
requests.


May I suggest to rename branch and trunk builds version to something
like 1.9.x-dev-r and 1.10.x-dev-rXXX? Never replace 'x' with the
current version patch version. I.e. '1.9.x-dev-r1701757'.

Because versions like 1.9.2.1 may confuse users. It's very hard to
find difference between 1.9.1.2 and 1.9.2.1 to distinguish official
releases from development builds.

Thanks!
I agree with u that the version numbering is not too clear and I also 
tend to agree that adding the revision number to the version number 
makes sense given the target audience of MaxSVN.


If I understand u right, then u are suggesting not to use SVN's patch 
version in MaxSVN version numbering scheme. I thought having that 
directly in the version number available would actually benefit users, 
because they would directly see which SVN version a MaxSVN version is 
based on.


I also think that Bert's suggestion to use the "dev" marker for versions 
which are based on a not-yet released build is quite good and drop that 
marker once a build is based on a released version.


What's ur opinion on using the following scheme instead:
1.9.x-y-rxxx-dev for versions not yet released
1.9.x-y-rxxx for versions based on SVN versions which are already released

x is the current minor version of the SVN version
y is a running number for MaxSVN builds
rxxx is the SVN revision a build is based on

So in case of the current 1.9 MaxSVN releases this is how with the other 
scheme things would look like:

1.9.0.1 -> 1.9.0-1-r1692833
1.9.1.1 -> 1.9.1-1-r1694136-dev
1.9.1.2 -> 1.9.1-2-r1698174
1.9.2.1 -> 1.9.2-1-r1701493-dev

Regards,
Stefan

Re: Announcing MaxSVN

[Ivan Zhakov]

On 7 September 2015 at 18:47, Stefan  wrote:
> Hi,
>
> I'm pleased to announce the availability of a new distribution of SVN
> called: "MaxSVN".
> In contrast to other SVN distributions this one is a bit different since it
> aims towards being used primarily to support SVN development rather than
> being used in production environments.
>
> Its primary purpose is to test and identify issues of SVN against the latest
> build tools and dependencies on Windows.
>
> It can however also be useful in other situations like if you wanna check
> whether a current development branch solved a particular issue or to check
> out the new features in an upcoming SVN release before it becomes available
> as part of a final release.
>
> Please note once more that I strongly suggest against using MaxSVN in your
> daily productive use. Please stick with one of the already available Windows
> distributions. A list of these can be found on the MaxSVN webpage:
> http://www.luke1410.de/typo3/index.php?id=97
>
> Also understand that MaxSVN is a product distributed, maintained and created
> by myself and is not directly associated with the Apache Subversion project.
>
> The latest current available builds are:
> - 1.7.22.2 (current latest 1.7 released version)
> - 1.8.14.2 (current latest 1.8 released version)
> - 1.8.15.1 (current 1.8 preview version)
> - 1.9.1.2 (current latest 1.9 released version)
> - 1.9.2.1 (current 1.9 preview version)
> - 1.10.0.2 (current 1.10 preview version)
>
> Feel free to send any feedback directly to me by mail or use the bugtracker
> at http://www.luke1410.de:8090/browse/MAXSVN to add bugreports/feature
> requests.
>
May I suggest to rename branch and trunk builds version to something
like 1.9.x-dev-r and 1.10.x-dev-rXXX? Never replace 'x' with the
current version patch version. I.e. '1.9.x-dev-r1701757'.

Because versions like 1.9.2.1 may confuse users. It's very hard to
find difference between 1.9.1.2 and 1.9.2.1 to distinguish official
releases from development builds.

Thanks!

-- 
Ivan Zhakov

Announcing MaxSVN

[Stefan]

Hi,

as suggested by danielsh when talking about MaxSVN, I also take the 
chance to announce MaxSVN hereby on the dev list quickly because this 
distribution is mainly focusing to help with SVN development/testing itself.


The full announcement is on the users list "Announcing MaxSVN".

As stated there, this distribution of the SVN command line tools 
primarily aims to test SVN against the latest build tools and 
dependencies on Windows and is not supposed to be used in production 
environments.


MaxSVN homepage: http://www.luke1410.de/typo3/index.php?id=97
MaxSVN bugtracker: http://www.luke1410.de:8090/browse/MAXSVN

Regards,
Stefan