I think maybe once per month might be reasonable? Or 6 weeks? I don't know exactly what exact timing would make sense.
I'm not necessarily suggesting to break up features into smaller pieces and release them in parts. If a feature takes longer than a release cycle to build then it just comes out in the cycle when it is ready. My point is that you will have less numbers of large features per release with this strategy. Of course it will be required for the feature owner of a large feature to have a branch for development and be somewhat challenging to stay abreast of the trunk changes but it's doable especially with git. On Nov 11, 2011, at 1:50 PM, Jun Rao <jun...@gmail.com> wrote: > Taylor, > > What's the release cycle that you are looking for? > > Also, for big features like replication, it may be hard to decompose it > into multiple releases. We can probably stage it so that some of the more > advanced stuff (e.g., rebalance with new brokers) are released later. > However, even to get the basic replication work done requires significant > changes. Any suggests on how to do this better is welcomed. > > Thanks, > > Jun > > On Fri, Nov 11, 2011 at 1:32 PM, Taylor Gautier <tgaut...@tagged.com> wrote: > >> No - just that big feature changes are more risky than smaller ones >> and having smaller upgrades helps identify unexpected issues more >> easily. >> >> Having fixed time length releases reduces the tendency for releases to >> grow larger. >> >> Another benefit of frequent small releases is that you'll get good at >> it so the process should become easier and more routine with time. >> With big releases and long periods of real time in between this won't >> be as likely to happen. >> >> >> >> On Nov 11, 2011, at 1:08 PM, Jun Rao <jun...@gmail.com> wrote: >> >>> Hi, Taylor, >>> >>> Are you more worried about bug fixes? If so, we can have some fixed >> release >>> interval for bug fix releases. >>> >>> Thanks, >>> >>> Jun >>
