[zeromq-dev] 2.1.8?

Pieter Hintjens ph at imatix.com
Mon Aug 29 13:53:04 CEST 2011

On Mon, Aug 29, 2011 at 1:27 PM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:

> I might be alone in this, but I've found the treatment of 2.1.8-rc1
> pretty confusing. E.g. in my expectations any rc is always followed by
> an actual release of the same version numbers. If you want to uniquely
> version releases, that's nice too, but then it would be more sensible
> (to me) to unpublish the release candidate from e.g. the downloads
> page.

You're not the only one to be confused. In the past we unpublished
stable releases that had flaws in them.

The last time we discussed this the consensus was to stick to a unique
release/version number that defined major/minor compatibility, and to
tag releases as alpha/beta/rc depending on their maturity. So in this
case when we found an issue in 2.1.8, the choice was either to delete
the release, or to tag it as 'rc'.

It seems tagging the release as 'rc' annoyed several people, so next
time we'll just delete such cases and skip to the next release number.
That leaves gaps but is less surprising.

If anyone has alternative suggestions, shoot. The requirements are:

- unique version numbering that indicates major/minor compatibility,
plus patch level (this rules out making 2.1.8-rc, 2.1.8-rc2,
2.1.8-stable for instance).
- tagging of some kind that indicates maturity (presumably alpha, beta, and rc).
- handling of exceptions, i.e. a release that turns out to be more or
less mature than expected (a beta that has no issues reported on it,
or a stable that has a serious issue).


More information about the zeromq-dev mailing list