cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Parashuram Narasimhan (MS OPEN TECH)" <panar...@microsoft.com>
Subject RE: [DISCUSS] continuous build and release process
Date Thu, 18 Sep 2014 17:28:04 GMT
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:kamrik@google.com] 
Sent: Thursday, September 18, 2014 7:51 AM
To: dev@cordova.apache.org
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
​
Mime
View raw message