Dear list, Since the Gitorious project started, the master branch has been where most development has been happening; and at the same time we have tried to keep the master branch stable enough to be used for deployment in a production environment. In early 2011, we started creating stable releases of Gitorious, following a versioning scheme described in this blog post: http://blog.gitorious.org/2011/01/10/versioning-gitorious/.
The process of shipping a new release of Gitorious is fairly simple: Once a new feature (in the master branch) is complete enough to provide a fairly complete new feature, we increment the Gitorious::VERSION constant in lib/gitorious.rb to a new major/minor/patch level, commit that change, create an annotated tag describing the new feature and push the new tag to the mainline repository. As you probably know, we're currently making some quite major changes to Gitorious. This means that new features will be added to the mainline repository which will introduce quite big changes in how things work. An example is our new code browsing tool, which will both be more performant and provide a very pretty interface for reading source code on Gitorious. We want to make it possible for you to decide for yourself whether you want to go with the latest and greatest or stay with the old and tested. Which is why we're introducing a new branching model for Gitorious, based on git-flow: http://nvie.com/posts/a-successful-git-branching-model/. The git-flow tools support this workflow, and will help us not forget to keep our branches in the correct state. *These are the changes:* 1) The "master" branch of gitorious/mainline will contain features that have been shipped in a Gitorious release As we set up the new infrastructure for gitorious.org, we will automatically deploy anything that's committed on the master branch to gitorious.org. This means that anything that's merged into the master branch needs to be of "production quality". 2) The "next" branch of gitorious/mainline will contain the latest features as they are completed We will be using feature branches (described below) to implement new features in Gitorious. Once a feature branch is completed, it will be merged into the "next" branch. To run your Gitorious server with the bleeding edge, you should run from this branch. Although we will not merge any changes that eg. has failing tests into this branch, we will allow more experimentation in this branch. Furthermore, we may remove features from this branch, so use it at your own risk. 3) Merge requests should usually be proposed to the "next" branch If you're contributing a new feature to Gitorious, you should propose it merged with the "next" branch. The exception is if you're contributing a bug fix for something that is in master; in this case you should propose it merged into master. 4) Hotfixes/bug fixes will be started from and merged into master and backported to "next" 5) New releases are started from "next", prepared in a release branch, and then merged into master. What do you think? Cheers, - Marius -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected]
