On Thu, Nov 10, 2011 at 2:01 AM, Martin Sustrik <[email protected]> wrote:
> Additionally, if Pieter is going to take over and maintain 3.1, there'll > be only one process and one ego left. I don't think there's any reason > to keep the repos separated then. "ego" is just an analogy. This is not about whether or not "Pieter maintains 3.1". I'll try to explain where I see the inherent conflict that we resolved with multiple gits. Anyone who can fit the story below into a single git repository, please do... :) The nvie.com model is nice, and it's close to the original model I proposed ages ago when we first discussed git workflows, but it does not actually support the maintenance / contribution model that has worked for us so far. That is: * Any major.minor version that is being used by people can be maintained as long as there is someone willing to make patches. * The maintainer's job is to manage those patches, enforce the relevant tracking and testing process, and create properly-packaged releases. * We can maintain any major.minor version as long as there are users. So today, if a 2.0.11 user sends a pull request, I will apply it, and we will eventually get a new release. The maturity/deprecation cycle of versions is 100% defined by user demand, not by decree from the maintainer. I have no patches for 2.2, so no users, so the project will naturally die. If 0MQ was always backwards compatible with itself, in API and protocol, we'd stick on the same major.minor version forever, and we could make a single master as "production quality latest release". However an essential freedom has been to break 0MQ compatibility arbitrarily as long as versioning is done properly. There is thus an inherent conflict between the interests of users (long term stability guaranteed by use) and developers (freedom to break anything they need to), when it comes to git. In reality the conflict is resolved by users effectively "voting" on versions. No-one really trusts or uses 3.0, thus we can kill it. (This was predictable at the time too, but allowing the devs to make that mistake was also an essential freedom). There is no "latest production master" of 0MQ, and trying to present this almost throttled our release cycle, last year. As we've seen, the freedom to maintain multiple conflicting "realities" (2.1 vs. 3.0 vs. 4.0) is essential. The alternative would by now have been a choice between forced upgrade, or no experimentation. In summary: my job as maintainer is to allow the community to decide on the life-cycle of 0MQ versions by voting, i.e. by sending patches, and to maintain as many such versions in parallel as the developers decide to inflict on the world. The maintainer has no opinion on the worth or status of any particular version. Further, the maintainer does not allow developers to define "latest production version" either. This is 100% decided by users. Perhaps 0MQ is unique in allowing users to own the process like this but for me it's been hugely successful in stimulating contributors, and in reducing the risk of change. The main cost has been surprise and some redundant work (e.g. applying the same patch to multiple releases). -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
