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
