You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by cmarcelk <gi...@git.apache.org> on 2014/10/13 22:02:53 UTC
[GitHub] cordova-coho pull request: CB-7774 capture updates from Hangout an...
GitHub user cmarcelk opened a pull request:
https://github.com/apache/cordova-coho/pull/53
CB-7774 capture updates from Hangout and mailing list
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/cmarcelk/cordova-coho CB-7774
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cordova-coho/pull/53.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #53
----
commit baecee872abc8028d840229c83d133b5957b0dd7
Author: Marcel Kinard <cm...@gmail.com>
Date: 2014-10-13T20:00:47Z
CB-7774 capture updates from Hangout and mailing list
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
[GitHub] cordova-coho pull request: CB-7774 capture updates from Hangout an...
Posted by cmarcelk <gi...@git.apache.org>.
Github user cmarcelk commented on a diff in the pull request:
https://github.com/apache/cordova-coho/pull/53#discussion_r18838799
--- Diff: docs/versioning-and-release-strategy.md ---
@@ -19,17 +19,100 @@
#
-->
-# Versioning and Release Strategy
+# Versioning Strategy
-## Versioning Strategies
- 1. `SemVer` ([Semantic Version](http://www.semver.org))
- * Used by platforms, plugman, CLI, core plugins
- * Is important when describing dependencies in a sane way (e.g. within plugin.xml files)
+## 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](http://www.semver.org)) 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`
+prefix.
-## 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
+code
+
+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 <engine> 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).
--- End diff --
Agreed. I think my separate commit on this topic passed this feedback in flight, so see if the current content in master address your feedback.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
[GitHub] cordova-coho pull request: CB-7774 capture updates from Hangout an...
Posted by cmarcelk <gi...@git.apache.org>.
Github user cmarcelk commented on a diff in the pull request:
https://github.com/apache/cordova-coho/pull/53#discussion_r18835781
--- Diff: docs/versioning-and-release-strategy.md ---
@@ -19,17 +19,100 @@
#
-->
-# Versioning and Release Strategy
+# Versioning Strategy
-## Versioning Strategies
- 1. `SemVer` ([Semantic Version](http://www.semver.org))
- * Used by platforms, plugman, CLI, core plugins
- * Is important when describing dependencies in a sane way (e.g. within plugin.xml files)
+## 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](http://www.semver.org)) 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`
+prefix.
-## 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
--- End diff --
Agreed. Fixed in a separate commit.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
[GitHub] cordova-coho pull request: CB-7774 capture updates from Hangout an...
Posted by agrieve <gi...@git.apache.org>.
Github user agrieve commented on a diff in the pull request:
https://github.com/apache/cordova-coho/pull/53#discussion_r18806936
--- Diff: docs/versioning-and-release-strategy.md ---
@@ -19,17 +19,100 @@
#
-->
-# Versioning and Release Strategy
+# Versioning Strategy
-## Versioning Strategies
- 1. `SemVer` ([Semantic Version](http://www.semver.org))
- * Used by platforms, plugman, CLI, core plugins
- * Is important when describing dependencies in a sane way (e.g. within plugin.xml files)
+## 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](http://www.semver.org)) 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`
+prefix.
-## 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
+code
+
+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 <engine> 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`?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
[GitHub] cordova-coho pull request: CB-7774 capture updates from Hangout an...
Posted by mmocny <gi...@git.apache.org>.
Github user mmocny commented on a diff in the pull request:
https://github.com/apache/cordova-coho/pull/53#discussion_r18836492
--- Diff: docs/versioning-and-release-strategy.md ---
@@ -19,17 +19,100 @@
#
-->
-# Versioning and Release Strategy
+# Versioning Strategy
-## Versioning Strategies
- 1. `SemVer` ([Semantic Version](http://www.semver.org))
- * Used by platforms, plugman, CLI, core plugins
- * Is important when describing dependencies in a sane way (e.g. within plugin.xml files)
+## 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](http://www.semver.org)) 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`
+prefix.
-## 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
+code
+
+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 <engine> 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).
--- End diff --
With the caveat, that we still semver CLI appropriately. The "bar" here is: will this new CLI add features or break compatibility with existing plugins/platforms/projects. If not, its just a point release. However, updates to the pinned version may often correspond with new CLI features (new config settings or whatnot) and thus a MINOR bump may be common.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
[GitHub] cordova-coho pull request: CB-7774 capture updates from Hangout an...
Posted by cmarcelk <gi...@git.apache.org>.
Github user cmarcelk closed the pull request at:
https://github.com/apache/cordova-coho/pull/53
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
[GitHub] cordova-coho pull request: CB-7774 capture updates from Hangout an...
Posted by cmarcelk <gi...@git.apache.org>.
Github user cmarcelk commented on a diff in the pull request:
https://github.com/apache/cordova-coho/pull/53#discussion_r18834641
--- Diff: docs/versioning-and-release-strategy.md ---
@@ -19,17 +19,100 @@
#
-->
-# Versioning and Release Strategy
+# Versioning Strategy
-## Versioning Strategies
- 1. `SemVer` ([Semantic Version](http://www.semver.org))
- * Used by platforms, plugman, CLI, core plugins
- * Is important when describing dependencies in a sane way (e.g. within plugin.xml files)
+## 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](http://www.semver.org)) 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`
+prefix.
-## 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
+code
+
+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 <engine> 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"
--- End diff --
Agreed. Fixed.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
[GitHub] cordova-coho pull request: CB-7774 capture updates from Hangout an...
Posted by mmocny <gi...@git.apache.org>.
Github user mmocny commented on a diff in the pull request:
https://github.com/apache/cordova-coho/pull/53#discussion_r18836698
--- Diff: docs/versioning-and-release-strategy.md ---
@@ -19,17 +19,100 @@
#
-->
-# Versioning and Release Strategy
+# Versioning Strategy
-## Versioning Strategies
- 1. `SemVer` ([Semantic Version](http://www.semver.org))
- * Used by platforms, plugman, CLI, core plugins
- * Is important when describing dependencies in a sane way (e.g. within plugin.xml files)
+## 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](http://www.semver.org)) 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`
+prefix.
-## 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
+code
+
+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 <engine> 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"
--- End diff --
I think we discussed adding a new "cordova upgrade" command, which would install the new pinned versions of all platforms (possibly replacing, possibly alongside, existing platforms), and not attempt to update a specific platform in-place.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
[GitHub] cordova-coho pull request: CB-7774 capture updates from Hangout an...
Posted by agrieve <gi...@git.apache.org>.
Github user agrieve commented on a diff in the pull request:
https://github.com/apache/cordova-coho/pull/53#discussion_r18806877
--- Diff: docs/versioning-and-release-strategy.md ---
@@ -19,17 +19,100 @@
#
-->
-# Versioning and Release Strategy
+# Versioning Strategy
-## Versioning Strategies
- 1. `SemVer` ([Semantic Version](http://www.semver.org))
- * Used by platforms, plugman, CLI, core plugins
- * Is important when describing dependencies in a sane way (e.g. within plugin.xml files)
+## 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](http://www.semver.org)) 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`
+prefix.
-## 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
+code
+
+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 <engine> 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"
--- End diff --
nit: I think it's "update" not "upgrade" for the command.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
[GitHub] cordova-coho pull request: CB-7774 capture updates from Hangout an...
Posted by mmocny <gi...@git.apache.org>.
Github user mmocny commented on a diff in the pull request:
https://github.com/apache/cordova-coho/pull/53#discussion_r18835133
--- Diff: docs/versioning-and-release-strategy.md ---
@@ -19,17 +19,100 @@
#
-->
-# Versioning and Release Strategy
+# Versioning Strategy
-## Versioning Strategies
- 1. `SemVer` ([Semantic Version](http://www.semver.org))
- * Used by platforms, plugman, CLI, core plugins
- * Is important when describing dependencies in a sane way (e.g. within plugin.xml files)
+## 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](http://www.semver.org)) 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`
+prefix.
-## 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
--- End diff --
This is correct as of today, but we would prefer to amend to say "most recent *compatible* version". I know you are capturing today's behaviour here, but just calling this out.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
[GitHub] cordova-coho pull request: CB-7774 capture updates from Hangout an...
Posted by cmarcelk <gi...@git.apache.org>.
Github user cmarcelk commented on a diff in the pull request:
https://github.com/apache/cordova-coho/pull/53#discussion_r18834684
--- Diff: docs/versioning-and-release-strategy.md ---
@@ -19,17 +19,100 @@
#
-->
-# Versioning and Release Strategy
+# Versioning Strategy
-## Versioning Strategies
- 1. `SemVer` ([Semantic Version](http://www.semver.org))
- * Used by platforms, plugman, CLI, core plugins
- * Is important when describing dependencies in a sane way (e.g. within plugin.xml files)
+## 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](http://www.semver.org)) 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`
+prefix.
-## 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
+code
+
+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 <engine> 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 --
Agreed. Fixed.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org