One of the core team members, Riccardo Spagni (aka fluffypony) has recently proposed a different approach to hard fork management, provoking a vivid discussion on the Monero Forum.
Seeing as how there are going to be things that will have to be introduced via a hard fork in future it stands to reason that we have to look at better ways of doing this than the current “fork and pray” approach. The scheme outlined below does not force miners / nodes to adopt a fork if we add something stupid in, but it creates a more fluid network that can robustly handle changes.
Basic bottom line: every 6 months there’s a hard fork. You get 1 hard fork’s grace before you have to update or be left behind.
Every 6 months, either on March 15 + September 15 or on April 15 + October 15, the Monero network will have a hard fork. 30 days before the fork we will have a code freeze + tag + release, and if there are no major changes we’ll have an increase in the protocol version (ie. that’s at a minimum). A similar fork system to Bitcoin will apply, whereby a rollover to the new code after the trigger block will only occur if a sufficient number of miners are running the new code.
Anything that is more of a soft fork will kick in immediately (as long as it doesn’t drop pre-fork clients off the network). Anything on the p2p layer (ie. hard forkable) will be kept in the wings until the next fork date (as roughly estimated from block height) and then is enabled.
You may read the rest and take part in the discussion here: https://forum.getmonero.org/4/academic-and-technical/303/a-formal-approach-towards-better-hard-fork-management