At the last contributors meeting we discussed the need to balance fast turn-around of features while maintaining stability of release branches. The conclusion we came to is to do time based release - a 3 month release cycle seemed to make most sense to the group. This rule would be combined with another one - that no features or non-P1 bug fixes would be allowed after the branch is cut to guarantee branch stability.
Now we need to decide what to do with 0.9 release that was in progress while the discussions were going on. In the past, we have been waiting for 1-2 month to stabilize the release. Basically, we deployed it internally at Yahoo and would only call a release vote once the number of bugs reported by yahoo users subsided. While this meant that Pig produced very stable releases, they did take a long time to come out.
We would like to propose a change in this approach. As of now, 0.9 is feature complete and there are no outstanding P1 or even P2 bugs against it. Unless I hear strong objections, I would like to call a release vote early next week. We would need to clearly state that this release is likely to be less stable than previous .0 releases (especially given the amount of change that went in.). Once we get sufficient number of bug fixes, we would call for 0.9.1 release which would be similar in stability to our earlier .0 release. This way we can get a release out early for everybody to play with and will also allow us to produce a more stable release a bit later.
Your comments and questions are welcome!