A slightly different model to consider: Github-flow, which is used within Github. It is similar to the Fedora model, but incorporates code review: http://scottchacon.com/2011/08/31/github-flow.html
Although I'm still coming up to speed on the Git world, I'm starting to see some patterns. Git-flow seems optimized for projects that have very structured release cycles. This seems in line with the way DSpace releases have been handled lately. Github-flow (and therefore the Fedora model?) seems to be designed for projects that push their updates onto production systems continuously. For Dryad development, the Github-flow model seems very attractive. I'm hoping that it will give us the flexibility to develop our features more asynchronously. Rather than having formal releases, we would like to simply push out each feature as it becomes stable. Features that are not yet stable can remain in their own branches without delaying the release of the features that are stable. Hopefully, this will also allow us to more easily migrate a single feature/branch to the core DSpace codebase when appropriate. Of course, there is no need for the core DSpace development to use the same model as Dryad. Dryad is naturally pushed towards continuous releases by the changing needs of our customer base. DSpace, on the other hand, has a need to provide stable releases of the codebase that can be distributed. So it may make sense for the Dryad model to differ somewhat from the DSpace model. --- Ryan Scherle --- Data Repository Architect --- Dryad Digital Repository ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
