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

Reply via email to