ZeroMQ

Creating Stable Releases

We want some guarantee of stability for a production system. In the past, this meant taking unstable code and then over months hammering out the bugs and faults until it was safe to trust. iMatix’s job, for years, has been to do this to libzmq, turning raw code into packages by allowing only bug fixes and no new code into a “stabilization branch.” It’s surprisingly not as thankless as it sounds.

Since we went full speed with C4, we’ve found that the Git master of libzmq is mostly perfect, most of the time. This frees our time to do more interesting things, such as building new open source layers on top of libzmq. However, people still want that guarantee: many users will simply not install except from an “official” release. So, a stable release today involves two things: first, a snapshot of the master taken at a time when there have been no new changes for a while and there are no dramatic open bugs; and second, a way to fine-tune that snapshot to fix the critical issues remaining in it.

This is the process we explain in this section.

The project SHALL have one branch (“master”) that always holds the latest in-progress version and SHOULD always build.

This is redundant because every patch always builds, but it’s worth restating. If the master doesn’t build (and pass its tests), someone needs waking up.

The project SHALL NOT use topic branches for any reason. Personal forks MAY use topic branches.

I’ll come to branches soon. In short (or ...