cordova-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CB-7774) update strategy for versioning
Date Tue, 14 Oct 2014 03:07:34 GMT


ASF GitHub Bot commented on CB-7774:

Github user agrieve commented on a diff in the pull request:
    --- Diff: docs/ ---
    @@ -19,17 +19,100 @@
    -# Versioning and Release Strategy
    +# Versioning Strategy
    -## Versioning Strategies
    - 1. `SemVer` ([Semantic Version](
    -   * Used by platforms, plugman, CLI, core plugins
    -   * Is important when describing dependencies in a sane way (e.g. within plugin.xml
    +## Version Format
    -CLI exists in both lists because its version has the format: `CadVer-SemVer`
    - * E.g.: `3.0.0-0.5.1`
    +`SemVer` ([Semantic Version]( will be used as the
    +version format for all components, including platforms, plugman, CLI, core
    +plugins. Doing so is important when describing dependencies in a sane way
    +(e.g. within plugin.xml files). Although the CLI previously used a 
    +`CadVer-SemVer` format, it now uses a simple SemVer format. The `CadVer` format
    +is no longer used in any Cordova components. The plugins no longer have an `r`
    -## Release Strategies
    +The semantics of `SemVer` should be followed, bumping the appropriate digit
    +based on the impact of the new content.
    +## Branching and Tagging
    +All components also follow the same branching and tagging strategy, including
    +plugins and tools. A `major.minor.X` release branch (i.e., "3.7.x") should be
    +created, and any fixes should be appended to that release branch. New content
    +should be on the master branch, and a new release branch created at release
    +time. When a release is performed, a release tag is added to the appropriate
    +branch (i.e., "3.8.0" tag is put on the "3.8.x" branch).
    +## Version Behavior
    +Plugin versions will all be separate and independent. So there may be a "1.2.0"
    +of the Device plugin, and a "3.4.5" of the Camera plugin at the same time.
    +The bumping of the version numbers of each plugin should be appropriate to the
    +new content added to that plugin. The `cordova plugin add` command will add
    +the most recent version of that plugin by default, though alternately the user
    +may manually specify an explicit version of that plugin to be installed (i.e.,
    +`cordova plugin add org.apache.cordova.device@1.2.0`). Plugin docs should be
    +stored in each plugin repo, so that the docs are versioned with their source
    +Platform versions will all be separate and independent. So there may be a
    +"3.7.0" of the iOS platform and a "4.0.0" of the Android platform at the same
    +time. The bumping of version numbers of each platform should be appropriate
    +to the new content being added to that platform. The `cordova platform add`
    +command will add a platform version specific to the CLI by default, though
    +alternatively the user may manually specify an explicit version of that
    +platform to be installed (i.e., `cordova platform add android@4.0.1`).
    +The CLI will hold the list of default versions for each platform
    +(i.e., platform version pinning). Platform docs should be stored in each
    +platform repo, so that the docs are versioned with their source code.
    +Platforms will have an &lt;engine&gt; tag or equivalent, to specify when a
    +platform needs a newer version of the CLI.
    +`cordova-js` versions should continue to be single-sourced, meaning that when
    +`cordova-js` is used by multiple components such as `cordova-lib` or 
    +`cordova-android`, the `cordova-js` version number should not be manually
    +modified upon insertion to the consuming component, but instead should retain
    +its build-time value. This means that there may be different versions of 
    +`cordova-js` in use across each Cordova component.
    +`cordova-lib`, `plugman`, and CLI versions will all be separate. So there
    +may be a "0.25.3" version of `plugman` and a "1.3.2" version of `cordova-lib`
    +and a "3.8.0" version of the CLI at the same time. The bumping of version
    +numbers of each of the tool components should be appropriate to the new
    +content being added to that individual component. The exception to this
    +is that when a new platform is released, and the platform pin in the CLI
    +is correspondingly updated, the CLI receives a bump to its third digit, no
    +matter the size of the version bump to those platform(s).
    +When a user updates the version of the CLI they have installed, this CLI
    +update has no effect on the platform and plugin versions that are already
    +installed in their project, but they may receive a warning or notice if
    +the installed platform versions are older than the versions pinned by
    +the CLI. However, if they subsequently do a "cordova platform upgrade"
    +they will get the pinned version based on the CLI.
    +The CLI version number will be the "name" of the Cordova version. Thus
    +tools and platform updates will cause a bump of the "Cordova version",
    +but plugins will not.
    +Where Cordova components have dependencies upon other Cordova components
    +(i.e., CLI depends on `cordova-lib`) or upon third-party components (i.e.,
    +CLI depends on `nopt`), the `package.json` should fully pin the version of
    +the dependent component (i.e., "nopt: "2.3.4"). This is in lieu of 
    +npm-shrinkwrap since npm-shrinkwrap is not reasonably mature.
    +For users that want to install a "fixed recipie" of specific versions
    +of these components, there are two ways to do that:
    +- `cordova --save` and `cordova --restore`
    --- End diff --
    do you mean `cordova --experimental save plugins`?

> update strategy for versioning
> ------------------------------
>                 Key: CB-7774
>                 URL:
>             Project: Apache Cordova
>          Issue Type: Improvement
>          Components: Coho
>            Reporter: Marcel Kinard
> With the advent of independent platform releases, we need a strategy for how to version
all the Cordova components.
> See

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message