With regard to branch structure, I took some time to think and have a suggestion. Feel free to pick holes in it.
Major feature releases would continue to have major version numbers: e.g., 1.7, 1.8, 2.x and so on. Bug-fix releases would be minor releases: e.g., 1.7.1, 1.7.2, 1.7.x, etc. Major releases get their own branch, although it will probably be sensible to keep major features on their own JIRA branch before being merged on to the release branch. Once a major release "goes gold", bug fixes would be continued on that release branch, and the next major release would go to a new branch. Bug fixes on the current "gold" branch would be merged regularly in to the new major release branch, until that new major release branch is ready to "go gold", at which point the cycle would repeat, and new bug fixes would go on to the newly released major release branch. In the above scheme, master becomes deprecated, but there is still only one major release branch that is "gold" at any one time. We would not be in a situation where 1.7.x was still being developed on once 1.8.x has been released. <http://apache-ignite-developers.2346864.n4.nabble.com/file/n8939/Ignite_Source_Control.jpg> -- View this message in context: http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Release-Schedules-a-suggestion-tp8867p8939.html Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
