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 especially to Bert to state that, so you don't set too high expectations on my contributions which I won't be able to fullfill in the end. ;-)

That said, who knows what the future brings. Priorities might change. Still even if they don't I'm certainly expecting to keep my contributions active even after these unannounced plans are done. ;-)

Regards,
Stefan

Reply via email to