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"). >
