If you want to have a faster release cadence, then I think the answer is for _you_ (not Apache) to have a faster release cadence. It seems easy to look at Apache rules for releases and Linux rules for releases (as an underpinning for the features found in Git) and treat them as incompatible, but I don't think they should be.
* Go and fork the project code on GitHub. * Put your changes in there and PR them up into the Apache codebase. * If others want to, they can PR the code to you, and then you can PR the code up to the codebase (or the group of you could work as a community preparing PRs). * The one pushing into the Apache codebase needs to be confident that the code is covered by CLAs. * You can release in GitHub whenever you want. * The Apache release happens less often and follows the rules. We have some issues to 'defend' against: * Trademark understanding so that a project's releases on GitHub do not appear as being from Apache. * Making sure the system is not used for exclusionary reasons (though they'll often identify community problems as a root cause anyway). It's no different than what commercial companies are doing already, either by having internal forks or an 'upsell' public version; with both cases taking time for patches to work their way back in. Why not have subsets of the PMC doing the same? This takes the legal arguments out and gets us more focused on the 'but a singleton community is the apache way' gut unhappiness. Hen
