Release Process

The use of separate git repositories for ØMQ releases was introduced on 22 February starting with the 2.1 stable (rc1) release. This page tries to summarize the arguments for and against this approach.

Arguments for a single repository

It is 'least surprising': everything is in one place, and when you clone the repository you get all released versions, a full history, etc.
There are well-defined workflows for maintaining a development and a maintenance branch.
Many (most?) projects work like this and it works well.
This is how we've done it so far, and it's worked fine.

Arguments for separate repositories

Allows as many maintained releases (2.0, 2.1, 3.0,…) as there are people to manage such releases.
Removes the release process fully from the source git, which simplifies both processes.
It is no extra work to cherry-pick changes from the source git to release gits than between branches.
Scales better, each git is a person or team, and a focussed project.
Appears to allow much faster release cycles, since it's less work to make a release.

In summary, we (Pieter Hintjens and Martin Sustrik) found ourselves unable to make a stable release of 2.1 without deprecating the 2.0 stable release, which is heavily used in production. PH wanted a simpler release process and MS wanted to remove the maintenance work from the source git. After trying this separate git process, we can conclude that it is indeed significantly simpler than managing maint/master branches in the same git.