I think this is a good discussion. I agree with Taylor on the idea of doing smaller 0.7.* releases before the big 0.8 one. This will encourage people to keep adopting bug fixes and smaller features. Compare it to our wanting to upgrade to zookeeper 3.3.4 before 3.4.0. That being said, I would think we have to move to a new branch.
Thanks, Neha On Friday, November 11, 2011, Jay Kreps <jay.kr...@gmail.com> wrote: > In general I like this style of time-boxed monthly release planning. It > does make big disruptive changes harder but it makes small changes much > easier because they get out with regularity. It also gives a nice rhythm to > things. > > There are a couple of potential issues for switching to this right now > though: > > 1. To date our strategy has been to release at linkedin before doing an > open source release. The advantage of this is that linkedin uses kafka very > very heavily (literally thousands of producer and consumer processes, > hundreds of topics, and a half dozen clusters separated by SLA). These > rollouts take a lot of time and are really painful but I think they are > valuable for other users because they ensure that by the time we do an open > source release we are guaranteed pretty good quality. We have always found > lots of issue in the course of each rollout. I am not sure how well we > could manage this alignment with a more fixed schedule because the nature > of things is somewhat stop and start--we rollout out on a few test > clusters, then onto just some servers in a production cluster, then whole > cluster, etc. Each time we find an issue we stop and debug it and then. On > the other hand I am not sure how desirable it is to have kafka release > schedule tied to linkedin since we want it to be a community driven project. > 2. Our current focus for linkedin folks was going to be on replication > which will be a really disruptive set of features that need to be released > together. Moving this to a branch would essentially move at least half of > active development there too. Not sure if this is such a good idea. It > might be better to just take a few months and get this worked out. > > My personal opinion is that this would be a good change to make but we > should wait until after 0.8/replication goes out, at that point we should > be doing smaller iterations and the release alignment would be less of an > issue. > > Any thoughts from others? > > -Jay > > On Fri, Nov 11, 2011 at 2:07 PM, Taylor Gautier <tgaut...@tagged.com> wrote: > >> 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 >> >> >> >
