(05-09-2015, 02:55 AM)tigerw Wrote: [ -> ]Then why not have master as testing?
I see your point, there's no point in people testing the "testing" branch.
Perhaps the "testing" branch should be an "internal one", meaning people are not supposed to test it directly, and no official binaries exist for it. The adventurers would use the Master branch, the rest will use Stable, and when a bug is detected in Master which is related to what's in testing, stuff are pushed to testing.
In other words:
Code:
Master ---(bugfixes/rotations)---> Testing ---(rotations)---> stable ---> Binaries: Stable releases.
|
V
Binaries: "Nightlies" / call them whatever you want
Edit: Now that I think of it again, I don't see how it's better than having people test "testing", you can ignore my previous post.
The reason to not have master as testing is that you don't want a big feature pull request landing on the testing branch just before a promotion. By having a testing branch, features can land on master at any time, but are only promoted to testing periodically, so that all feature code in testing has been tested for a week or two before promotion.
Why did you delete the testing branch? I've given my reasoning behind it.
I didn't delete anything :P
The delayed-deploy makes sense, thanks.
I have evidence
.
But it was probably a mistake.
I agree with a testing branch too, and I have an idea for it, a testing server. When the testing branch is updated with new features or bugfixes, it would be fine if we had a server to test together.
It could have core dumps enabled to detect crashes or similar things.
Unfortunately, I lost my free vps
.
We could use mine. It's a very cheap VPS hosted in Germany.
doing builds so you just need to track that. It shouldn't be too difficult to write an auto update script.
I already wrote my own update script. it works very well. So I just have to wait for the builds to start