I am totally behind the idea of nightly builds! Great summary Marcel. My plan has been to start work on a nightly build system after independent platform releases are out the door.
Release branches For indy releases, my plan was to remove cutting release branches for cordova-js. Cordova-js would instead get a PLATFORM-VERSION tag each time a platform is releasing based on master. Cordova-js will also have to be released to npm for the browserify workflow. I have included it in the tools release process. We could create a release branch when this happens. Reverting versions when RCs fail is a pain. I think release branches are a good idea for our tools and plugins. On Fri, Sep 19, 2014 at 11:48 AM, Marcel Kinard <[email protected]> wrote: > > On Sep 18, 2014, at 1:28 PM, Parashuram Narasimhan (MS OPEN TECH) < > [email protected]> wrote: > > > 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? > > For plugins and tools, I suggest that we follow exactly the same model as > platforms. When we are ready to release a new cordova-plugin-camera, the > version bump is x.y+1.0 (i.e., "0.3.0" -> "0.4.0") instead of x.y.z+1. And > at the first rc, a branch is cut (i.e., "0.3.x"). And instead of creating a > tag of the form "r0.3.0" it be simply "0.3.0". Just like platforms. > > > I am guessing that this would be for platforms and the tools. > > Plugins and tools. To match how platforms work. > > > 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). > > From a versioning perspective, the version of each platform just runs on > its own line. There is no synchronization of version numbers across > platforms. cordova-lib/.../platforms.js has the table of all the > most-recent platform versions, and the cli gets bumped anytime a platform > gets bumped, which means it will move fast. The cli version drops the > suffix so it is a plain format like the platforms. The classical meaning of > "Cordova x.y.z" is gone, unless you want to overload the cli version for > that. Not entirely thought through or discussed yet. > > > In addition to release branches, should we also ensure that feature > branches are strictly followed - i.e. master is always stable? > > I think master should be stable. Test-before-push could be a suitable > substitute for strictly having topic branches. I mean, we're doing that > already, right? :-o > > > 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? > > Yes. > > Anyway, these are my opinions.
