github release procedure

Johannes Pfau nospam at example.com
Fri Jan 4 02:33:31 PST 2013


Am Fri, 04 Jan 2013 07:59:05 +0100
schrieb "Rob T" <rob at ucora.com>:

> 
> You did mention that (1) is more suitable for beta testers, so I 
> ask how is (2) not as suitable?

With (1) you can always use staging, it'll always be the latest beta.
With (2) you'll have to figure out the most recent branch (2.061,
2.062, 2.063).

But I think we can start with (2) and change to (1) later if we think
it's useful. Staging complicates the concept(on a cognitive level) and
it needs additional "human resources" to do the merges into it.


I think I understand the whole concept now. I seems to be a good
solution but it requires some discipline (basing changes on the correct
branches) so we should document it as clearly as possible. I'd strongly
recommend to only base regression fixes on release branches and usual
bug fixes on master (see my other message).


More information about the Digitalmars-d mailing list