About the release branches, is the idea that we continue to push stuff on master and then create a new 3.7.0 branch when we would like to release 3.7.0? I am guessing that this would be for platforms and the tools. How would this look when the platforms start getting released independently (we don’t have to answer that now, but I guess we will look at it when platforms do get released independently).
In addition to release branches, should we also ensure that feature branches are strictly followed - i.e. master is always stable? I am guessing that these release branches will live on forever and in case of security patches, we would go back and apply them to the each branch? About buildbot, we also run our tests on buildbot. Is there a way to buildbot master to be hosted by Apache infra, and all of us federate machines and test results to build bot? I am guessing that 1 person cannot run tests for all platforms, so it makes sense to have a way to let multiple people contribute platform specific slaves/device walls where these tests are run. -----Original Message----- From: Mark Koudritsky [mailto:[email protected]] Sent: Thursday, September 18, 2014 7:51 AM To: [email protected] Subject: Re: [DISCUSS] continuous build and release process +1 for release branches, reverting version bumps feels really awkward +1 for more continuous integration. And just to make sure more people +are aware of it, there is this buildbot running some CI http://108.170.217.131:8010/waterfall A half baked idea for a more automated release process: Talking only about the tools releases for now as I don't have experience with releasing the other parts. The idea is to have it scripted in two stages with all the human input concentrated between the two stages. The first stage would automatically collect some info and write out a "release config file" with values that need to be decided upon by humans. The release manager then edits that file (maybe even gets it reviewed/approved by others). Then the second automated stage would use that config file to prepare artifacts ready for voting. Coho already does much of that, but with the current release process [1] human inputs are spread between many points along the way which prevents more automation. [1] https://github.com/apache/cordova-coho/blob/master/docs/tools-release-process.md
