On Mon, Nov 1, 2010 at 5:00 PM, Martin Sustrik <[email protected]> wrote:
> "Release early, release often" principle has some drawbacks. People look > at an early version that is not stable enough and then avoid the project > even though it may have stabilised in the meantime. I think Joel Spolsky > had a blog about this long time ago. That's one conclusion. The other conclusion is that if you always take a version through to stability before starting on new functionality, you have a stable (fully working) version people can trust plus an unstable (richer) version people can experiment with. There is no real justification for having unstable code for more than a few weeks, let alone months or years. In 0MQ's case, we could have started with one pattern, one transport, and when that was totally stable, expanded it. This is the industry standard model for open source projects, 0MQ shouldn't be any different. There were specific unfortunate design aspects of 0MQ such as the use of asserts for error detection rather than internal consistency checking, and the lack of documentation on the protocol which made it harder to model explicitly and therefore to check. We learn these things, but releasing less frequently would make things worse, not better. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
