Hi,

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!

Olga

Reply via email to