Thanks for the reply. Here are some thoughts might be useful: 1. Create/update a wiki page about the definition of the version system; 2. Create wiki pages for the goals of each planned version, including stable and dev version, like 1.2, 1.3; 3. Tag the current master to be 1.0.8-rc1 or 1.1-rc1, and set an initial release date for the stable release, e.g Nov 30; 4. Create a branch only if we have to merge master with a major feature not on the goal list of the stable version; The goal for each version can be changed and the release date can be delayed. More RC versions can be released before the formal one. But the most important thing is, the users will have a version to test, to discuss and to fix. About the next release, I feel v1.1 is better than v1.0.8 because it saves a digit for all the following versions (v1.1.3 vs v1.0.8.3, etc). Personally, I'm not a big fan to the odd/even number style. I think all the features in master should be tested and stable enough for integration (otherwise it'd better stay in a branch as branching is very cheap in git). It just needs several beta and RC versions to make it stable. Using a whole minor number for testing is a waste. Again, if you think it worths the time, I would like to start contributing on wiki pages.