Transitioning to the new Release Process

[mist]

My understanding is that your understanding is somewhat different 
from initial proposal but that is where discussion has flow to 
since then and that makes me sad :)

They very reason to have staging is to have better replacement to 
beta process which simply does not work good enough currently. Is 
good to have a single branch all the time, which some obscure 
project maintainer can check from time to time to make sure his 
stuff still compiles and fire regression bug reports if needed. 
He may even have add this test to own continuous integration 
suite (I'd do this if I had a serious D project) to be notified 
when stuff goes wrong without paying any constant attention.

Attention is a key here. How many D projects are out there? How 
many of their maintainers pay close attention to newsgroup and 
read beta mail list? Compare this to being able to check your 
stuff on very next release at any moment you have time and want 
to.

I stand at the point that for open source projects release and 
development processes should care most about end users and 
developers and least - about maintainers. Maintainers should have 
perfect git and process knowledge anyway, or at some scales thing 
are doomed to be crewed (2.061 anyone?).

Thus I vote for a persistent staging branch.

>
> My understanding was that staging is worked on only during the 
> (short) time span from initiating a new release and finalizing 
> that release.
>
> Andrei