Transitioning to the new Release Process

foobar foo at bar.com
Sat Jan 12 00:22:27 PST 2013


On Friday, 11 January 2013 at 18:03:33 UTC, mist wrote:
> 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

I don't understand the problem you seem to see in the process.

I've been away from the PC so couldn't respond earlier but I did 
manage to read most of the wiki page and I think Johnathan did a 
very good job explaining the various concepts. The only thing 
missing IMO is CI:
It's already agreed that master is the development channel in the 
proposed process. The next logical step would be to generate 
nightly builds off of that branch. The staging branch is the 
"beta" channel - and also makes sense to have a periodical beta 
build. This depends on the release time span but something like 
fortnight or monthly beta builds makes sense to me.
the additional manual builds described on the wiki on staging or 
even before an official release on the version branch will be 
something like RCs.

Regarding pull requests targeting master, the current model *is* 
geared around that. Most contributions _should_ go to master (aka 
devel) and go through the full process. pull-requests for staging 
are meant for fixing regressions and critical bugs only, where 
there is _higher urgency_ for the fix that justifies the 
short-cut. Regular "bug fixes" should simply go through the 
regular process and will be released in the _next_ release.


More information about the Digitalmars-d mailing list