On Sunday, 24 April 2011 at 10:04, Per Inge Mathisen wrote: > This will have some consequences, like not being able to aim for a > stable release from master in a while,
I've wondered if the concept of "stable release" is actually useful for us. Looking at 2.3, it seems to languish mostly, while people work on new stuff. So, proposal for a more git-like workflow: -1. Get master into a reasonably stable state. 0. New features are developed in feature branches. Bugfixes to a specific feature go into the feature branch as well, even after it got merged. (Generally, merges go only in one direction, no back-merges from master into other branches.) 1. Merge feature branches deemed ready. 2. Test and get them really ready. 3. Release. 4. Goto 1. That way new features get released reasonably quickly, and we don't have to keep care of an outdated release branch. Also, work on features doesn't destabilize master before they're merged, and if they do after merging, they can be unmerged relatively easy again. Could maybe be enhanced with a wip branch where all currently worked on feature branches get merged regularly, to see how they work together. If a bugfix release is needed before the next "proper" release, it can just be branched from the release as needed. > * We merge Qt branch into master immediately. No objections from me. > * Once a new map format is ready, we can start experimenting with a > new map renderer. Of course, these things go together, so I assume > that the new map format will have a few revisions before it is > stabilized. > * The new map renderer should use shaders, but not require as much > hardware as the current. Consider this statement ironical? Only if you > have made a habit out of thinking that poor drivers mean weak > hardware. But lots of recent weak/cheap hardware now have quite decent > OpenGL ES 2 drivers. The new map renderer needs to be fast, > maintainable, and extensible. Shouldn't that just read "renderer"? I think our speed problem is still mostly model rendering. > * Meanwhile, we also need to get rid of the old scripting system, and > I am on the way there with the QtScript port. I am hoping that I can > concentrate on this, while someone else have a go at the map renderer. > This task does not need to be finished before stable release, but the > new script API should be stable by then. You said that scripts don't need to be deterministic because they can just run locally and send the results to other players. So a new way to cheat is to just run a custom script? > Other items that would be nice to have before a stable release: > * Login support for the game and masterserver. > * Observers. > * Replay. I've had this idea of having a git repository for each savegame, with a save committed every game tick. That could allow to replay, rewind and bisect games. (Maybe every tick is too much, even with a background thread though.) And when we have e.g. libgit2 integrated anyway, we could use it as autoupdate mechanism. A new release gets committed to the repo, the game automatically pulls it. Can also be used to detect manipulated data files. Though we might have to use single files instead of zip archives for the data, I think git doesn't do binary changes well (bup might help though: https://github.com/apenwarr/bup). _______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
