On Tue, May 17, 2016 at 01:09AM, endianignite wrote: > 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.
How would you propagate bug fixed among releases in this case? > 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.
signature.asc
Description: Digital signature
