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

MinRK benjaminrk at gmail.com
Tue Feb 15 19:58:09 CET 2011

>From the pyzmq side, I have encountered quite a few users who refuse to use
HEAD or 2.1.0 because they are in production situations and have policy
guidelines preventing the use of beta code.  Even if the code is actually
*more* stable than 2.0.10, the simple fact that it's called 'beta' means
many people are waiting for 2.1.1.

I am 100% behind using Pull Requests.  I even submitted one, before I
learned about the email/patch pattern.


On Tue, Feb 15, 2011 at 10:27, Chuck Remes <cremes.devlist at mac.com> wrote:

> Comments are inline.
> On Feb 15, 2011, at 11:09 AM, Pieter Hintjens wrote:
> > Problems:
> >
> > 1. It is rather hard to know what version of 0MQ to use:
> >  - The stable release is too out of date, has numerous flaws that
> > have been properly fixed in later versions
> Agreed. IMO, stable 2.0.10 causes problems for new users. Even though 2.1.0
> is "beta" we should probably encourage new users to *start* with it if they
> are new to the library. Stable 2.0.10 should be targeted for existing users
> who cannot (or will not) upgrade right now.
> >  - The development release, which fixes the major flaws, has no bug
> > fixes since it was released
> I don't think this is much of a problem. I think the community we are
> targeting is pretty comfortable with the "github way" which is to use HEAD.
> Of course, this assumes that care is taken to make sure HEAD is never
> broken.
> >  - The master HEAD has no formality, and can't be used except by small
> teams
> I'm not sure what you mean here. I agree it has little formality but the
> "small teams" part confuses me.
> > 2. New code (like the new xsub/xpub sockets) is not tested in a timely
> fashion
> >  - They are on topic branches that few people know about or work with
> >  - We have an unresolved conflict between stability and progress on the
> master
> My suggestion is that work on topic branches should be aggressively merged
> back to master. That way problems will come to light quicker and the code
> will get exercised more often. Also, managers of the topic branches should
> be *very* aggressive about merging master back into their branch so that
> they don't diverge too far away.
> So I guess I disagree with your Proposal #1.
> > Proposals:
> >
> > 1. Stop using topic branches for new development, use the master for this
> > 2. Rename the maintenance branch to match the actual version it covers
> (2.0.x)
> Agreed with #2.
> > 3. Start a new maintenance branch for 2.1.x so that patches can be
> > applied to 2.1.x releases
> Agreed with #3.
> > 4. Use github pull requests instead of email patches
> Absolutely. I was always a little confused about the whole
> email-to-ml-plus-magic-email-signoff process. It seemed too complicated when
> a pull request would be far simpler.
> I have an additional suggestion. I think we need a link to the 2.1.0 beta
> man pages from the web site. Many questions on irc are due to people using
> the master codebase while reading the online docs. Since they don't match up
> there is lots of confusion about zmq_term(), zmq_close(), ZM_LINGER, etc.
> This is a good conversation to have. The community has been growing; I see
> a lot more new names on irc and a lot more questions on this list so I know
> interest has been steadily growing. If we fix some of the issues related to
> how newcomers can contribute then I think we'll see a bit faster progress.
> cr
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110215/ae3b372e/attachment.htm>

More information about the zeromq-dev mailing list