The only other serious contender to a release management process would be git flow, i.e.,
http://nvie.com/posts/a-successful-git-branching-model/ https://github.com/nvie/gitflow If I was to summarize the difference, I think it comes down to whether origin/master reflects the development work we are doing towards the next release, or whether it reflects the current stable release, and the origin/develop branch is the piece that we currently work off of. I haven't worked in either of the two paradigms, having developed server-based software for far too long, and I'd like a discussion on the pros and cons so I can visualize the consequences of each choice. J On Thu, Aug 9, 2012 at 9:52 AM, Matthias Friedrich <[email protected]> wrote: > Hi, > > next small item on my release TODO list is a little bit of software > configuration management: We should decide on how we want to deal > with branches and tags. > > I don't have much experience with git, but I'd suggest a simple model > that most people are already familiar with. An old blog article of > mine describes this [1] (it's the second strategy discussed). There > are more complex models (people write lengthy papers about them) but > I've never really needed more than this. It's important to have clear > conventions that don't cause headaches or require advanced tool > mastery. > > Maven's release plugin supports this process perfectly, but I admit I > haven't used it with git before (with Subversion and Mercurial it > worked fine). If you want to take this approach, I'd document it on a > wiki page and post the link here for review. > > What do you think? > > Thanks, > Matthias > > [1] http://blog.mafr.de/2007/04/25/release-management/ > -- Director of Data Science Cloudera <http://www.cloudera.com> Twitter: @josh_wills <http://twitter.com/josh_wills>
