You think say the Linux kernel isn't useful? They've been on a three month cycle for ages, roughly one month merge window and two months of release candidates. Basically what you want is for everybody to time box what they can do before the next release, but you can't know if you don't know how long that'll be. Maybe if it's two months you'll do some quick enhancements and fixes but if it's six you do a deeper restructuring. If 90% of your developers have finished according to plan and 10% is threatening to hold up the release then the great majority won't be able to effectively use a small extension. It's better to just scrub the parts that aren't ready and say we're releasing now, sorry try again next merge window. Of course assuming that you have a large enough project that there'll be some release-worthy items every cycle and that people don't just submit shit for release no matter what state it's in. There's a lot less drama about who is important and can rush patches and delay releases if the answer is no, you can't. Only bugfixes during RC, if your code breaks shit or needs major rework you're bumped to the next version. If you don't have a person with balls managing that your releases will suck, but if you can't stand up to the developers it'll probably suck on a rolling basis too.