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