> On 24/09/2015 12:35, Bert Huijben wrote:
>> -----Original Message-----
>> From: Ivan Zhakov [mailto:ivan_at_visualsvn.com]
>> Sent: donderdag 24 september 2015 11:30
>> To: Daniel Shahaf <d.s_at_daniel.shahaf.name>
>> Cc: Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>; Stefan
>> <luke1410_at_gmx.de>; Johan Corveleyn <jcorvel_at_gmail.com>; Bert Huijben
>> <bert_at_qqmail.nl>; Subversion Development <dev_at_subversion.apache.org>
>> Subject: Re: Announcing MaxSVN
>>> On 24 September 2015 at 00:38, Daniel Shahaf <d.s_at_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
Received on 2015-09-27 19:19:30 CEST