cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Gill <>
Subject Re: [DISCUSS] continuous build and release process
Date Fri, 19 Sep 2014 20:20:20 GMT
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 <> wrote:

> On Sep 18, 2014, at 1:28 PM, Parashuram Narasimhan (MS OPEN TECH) <
>> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message