On Apr 24, 2011, at 6:43 AM, Christian Ohm wrote: > 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.
It sounds like the development model described in http://nvie.com/posts/a-successful-git-branching-model/ Is that what you would like to see us move towards? -------------------------------------------------------------------------- My Web Sites: http://dak180.users.sourceforge.net/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
