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
versions.
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
there.
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).
--
Regards,
Stefan Hett
