[zeromq-dev] Discuss: 0MQ releases and stability

Vick Khera vivek at khera.org
Wed Feb 16 17:24:35 CET 2011

On Wed, Feb 16, 2011 at 10:02 AM, Pieter Hintjens <ph at imatix.com> wrote:
> Do you have alternative proposals?  Just saying "it won't work" isn't
> terribly helpful.

I really like the FreeBSD model. They use subversion, and I'm most
familiar with it, so forgive me if I use svn terminology.  The
PostgreSQL project works similarly and they just switched to git, but
I am not that familiar with how they do branching, etc.

The HEAD branch is generally open for all developer to commit to.  It
is expected that any commits do not break the ability to build the
code (ie, no syntax errors) and that basic testing passes.

Major disruptive changes are done in a feature-specific branch, and
merged back when it is known to be reasonably working.  Sometimes such
branches end up abandoned, and that's ok, since there wouldn't be
anyone who could commit to keeping that feature working anyway.

Each major version of FreeBSD has a branch named like RELEASE_7 or
RELEASE_8.  So now FreeBSD 7.x lives inside just that one branch, and
FreeBSD 8.x lives in that other branch.  On release they are branched
as RELEASE_8_0 for FreeBSD 8.0.

>From time to time when suitable features are added, a new branch is
created, say RELEASE_8_1 from the current RELEASE_8, which would be
FreeBSD 8.1.

The patching works like this: all new fixes are added to the HEAD.
After they are tested, the supported versions that are affected are
patched as well.  This would mean RELEASE_8 as well as any RELEASE_8_x
versions that are not yet EoL.  The patched RELEASE_8.1 will not have
a new tag, but will identify itself as FreeBSD 8.1-p1 for example.

So now the users have the option of using fixed release, such as 8.1
and just getting the critical patches for it, OR they can just use the
latest version of FreeBSD 8 as of the day they do an svn update, which
helps testing before the next version 8.2 is made.

When it comes time to make FreeBSD 9.0 release, what will happen is a
policy change: no new crazy features or gratuitous changes to the
HEAD.  All focus changes to testing.  Once all regressions are fixed
and all known bugs dealt with (or deemed acceptable to exist), it is
tagged as RELEASE_9_0 and HEAD now gets opened up for hacking again.

The main issue is as stated: people to keep the older branches
current.  This can be scaled to meet the ability of the number of
developers, and should be a published list of "actively maintained"

I can envision keeping one branche (2.0) and the tip (which is to
become 2.1 ??) active.  The older branch only get data loss and
security fixes.  No new features.  Once 2.1 is release, 2.0 becomes

Given the rate of change, perhaps having a weekly or so snapshot
tarball would be helpful so people don't have to roll their own for

More information about the zeromq-dev mailing list