On Jun 7, 2010, at 6:34 AM, Martin Lucina wrote: > I would also prefer this solution. Martin, what is wrong with keeping the > current state of affairs and, at your option, either creating an > "experimental" or "socket-intergration" branch for your work on closer > integration with the BSD socket API, or just using the master branch for > that and branching "v2.0-stable" as and when required?
This thread was started by Martin S. yesterday when Zed complained about the python bindings being broken. He had a good suggestion for dealing with that scenario that I'll paraphrase here (apologies if I misrepresent the idea; this is my interpretation). Before making backward-compatibility breaking API changes, do one more point release. This provides up-to-date bug fixes for people relying on the old API without breaking their applications. For example, before modifying zmq_init, version 2.0.7 should have been released with the original zmq_init function signature for API compatibility. Immediately afterwards another release with the API breakage could be made. This release would increment the minor number and be called 2.1.0. It would be documented on the 0mq site that API compatibility is only guaranteed between patch releases (0.0.X) while minor releases (0.X.0) signify potential API incompatibility. Major releases (X.0.0) should indicate major functionality changes and/or significant API incompatibility. I agree with Martin L. that we should try and keep all 0mq source in the current sustrik/zeromq2 repository. Also, forking the "stable" version to a new repository splits the community (current watching sustrik/zeromq2) and inhibits the momentum that this project has been building. Synching between multiple remote repositories is a lot of trouble. Git has excellent branching capabilities so we should take advantage of those. The way most projects on github work is that master is the "stable" release. Experimental work is done on a branch and merged to master as it stabilizes. I like this approach and think it conforms to the Principle of Least Surprise. All IMHO, of course. cr _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
