Jun, You make valid points, but I still support Chris' viewpoint. If you go a long way and introduce a lot of big features in between releases you will slow down upgrades of your early adopters.
Consider myself as a case study. My team has been working on putting Kafka into production for approximately 2 months. In that time 0.7 has not materialized so we are going with 0.6. When we are stable we will have to consider moving to 0.7 at some point. But the size of the release in 0.7 makes me wary to do this and it will be a a major endeavor. As an architect and engineering manager I prefer smaller, easier pieces of functionality to consume. It makes upgrading easier and less risky. On Fri, Nov 11, 2011 at 12:00 PM, Jun Rao <jun...@gmail.com> wrote: > Hi, Chris, > > Thanks for bringing this up. My feeling is that fixed-time release is > probably more suitable for a more stable project. At this moment, we are > still developing major features in Kafka. The time it takes to add the > compression support is going to be quite different from adding the > replication support. So, for now, I'd rather do a major release with a > complete new feature, than at a fixed time interval. I agree that the > interval between 2 major releases shouldn't be significantly different. For > replication, I expect that it can be done in about 3-4 months once we get > started (should be in a week or two). We can still release bug fix releases > to patch critical bugs along the way. > > Jun > > On Fri, Nov 11, 2011 at 11:26 AM, Chris Burroughs < > chris.burrou...@gmail.com > > wrote: > > > With kafka 0.7 almost (*crosses fingers*) out I wanted to propose we > > adopt a fixed release schedule for major releases instead of by feature. > > So that -- for example -- we set a freeze date for 0.8.0 that is n > > weeks/months after 0.7.0 is completely out the door (something in the > > 2-4 month range perhaps). Major changes could could live in branches or > > (probably better) trunk with Crome-esque disabled feature flags. > > > > This would have a few benifits: > > - Trunk will need to remain more stable, which encourages more testing > > of trunk, RC releases, etc. in a virtuous cycle. > > - New features are available in a more predictable time frame to users > > (less need for internal patching if something is Really Important). > > - Because it's clear when new features are coming down the road, there > > is less temptation to add new features to bug fix releases. > > > > The primary downside is that the this requires more discipline when > > making larger changes (replication for example), and for this to work > > well we will also need more comprehensive and reliable unit/system > > tests. I think in the long run those downsides will prove to be virtues. > > > > To be clear, while I propose we stop making intentional changes at a > > fixed date, the actual release still can't happen until we are happy > > with the testing and bug-squashing that has gone into it (aka "when it's > > ready"). > > >
