subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Hett <>
Subject Re: conflict resolver status update (roll 1.10.0 alpha 1?)
Date Wed, 25 Jan 2017 12:34:03 GMT
On 1/25/2017 11:37 AM, Stefan Sperling wrote:
> On Tue, Jan 24, 2017 at 07:06:29PM +0000, Daniel Shahaf wrote:
>> Stefan Sperling wrote on Tue, Jan 24, 2017 at 19:06:13 +0100:
>>> On Tue, Jan 24, 2017 at 05:52:39PM +0000, Daniel Shahaf wrote:
> [...]
>>> If we do this, it would be good to know upfront what kind of binaries
>>> we can expect and should wait for. And that might complicate things.
>> That's just a synchronization problem and is easily solved.  I'm more
>> concerned that we'd need to come up with objective criteria for *which*
>> third parties we do or don't include in our own annoucnements.
> Our own release date is unpredictable. We cannot tell anyone when it will
> be done until it is done, which makes such synchronization difficult,
> not easy. So I really don't think we should wait for anyone else, or let
> anyone else wait for us after some prematurely announced release date
> which we missed.
> I'm also concerned about waiting for third parties which make promises in
> good faith but then turn out to be unable to follow up and cause deadlock.
> Your suggestion creates extra work for the release manager and I don't
> see the benefit that gives this idea an advantage over just announcing
> the release by itself and then letting third parties deal with binaries,
> as we have always been doing.

I'm certainly planning to push out alpha-releases of MaxSVN 1.10 as soon 
as the release process for alpha 1 starts. So I certainly hope this 
improves the situation a bit compared to alpha releases of previous SVN 
Certainly I donno how and if these builds would then be utilized by 
others to tests SVN 1.10. TBH, I doubt that many would use it as a test 
bed to provide feedback on the alpha-releases; but at least there would 
be pre-build Windows binaries for alpha-versions available then.

As stsp said above, I wouldn't hold back any alpha-version announcement 
though. Since I've got a day job which pays my bills, I'm not that 
flexible with investing as much time on MaxSVN/SVN as I wished I could, 
and sometimes things just get delayed because of some obstacles which 
require more than a few hours work to clean up (as you might be aware: 
the MaxSVN builds based on SVN 1.9.5 are still work in progress and 
while I'm currently pushing things hard on that side, it's still not 
ready atm to be released).
I'm quite sure that the situation is comparable for other products out 

I think it might help if I change the MaxSVN release process during the 
alpha/beta phase of 1.10 so to get alpha builds out faster. The main 
change I'm considering is to push out alpha builds independent from 
other MaxSVN releases (the ones based on older SVN versions) which atm 
is a promise of MaxSVN.
Another change I'm considering is to not update dependencies for the 
initial alpha-versions but rather reuse the ones used for previous 
builds and only after the initial MaxSVN-version got out, start the work 
to provide an alpha-build using upgraded dependencies.
Both of these things currently cost the most time when building MaxSVN 
and bare the highest risk factor concerning causes of release-delays for me.

So I'm quite positive that the gap between SVN 1.10-alpha1 being 
released and MaxSVN 1.10-alpha1 being available will be much shorter 
compared to previous releases.

But again as stsp said: The SVN project should not rely on this and 
postpone the alpha-release-announcements, since I can't give any 
promises from my side on my time-schedule.

For the situation with TortoiseSVN, I can't say much other than the 
current development branch (aka: trunk) was already switched a while ago 
to the SVN trunk. Nightly builds should be available already. That said, 
I don't see much speaking against TSVN alpha-builds based on 1.10 from a 
technical point of view. If you like I can try to contact Stefan to see 
what his opinion on this point is (I'm quite sure, he doesn't follow the 
dev list here).

Stefan Hett

View raw message