ew cordova release; no node package changes
> cordova@3.2.0@0.2.1 - patch to node package
> cordova@3.3.0@0.2.2 - new cordova release; patch to node package
> cordova@3.3.0@0.3.0 - minor to node package
> cordova@3.3.0@1.0.0 - major to node package (non-backwards compatible api
> change)
> cordova@3.4.0@1.1.0 - new cordova release; minor to node package
> cordova@3.4.0@1.1.1 - patch to node package
>
> I hope this helps to improve the cordova-cli versioning habit.
>
> Cheers!
> Michael
>
proach will not work with fuzzy dependency
resolving in npm.
According to semver, we can use x.y.z+a.b.c, but npm's implementation of
semver does not
support this. At least, it didn't a year ago when I wrote up my original
Cordova CLI versioning
propose [1].
We're pretty much maki
cordova release; patch to node package
cordova@3.3.0@0.3.0 - minor to node package
cordova@3.3.0@1.0.0 - major to node package (non-backwards compatible api
change)
cordova@3.4.0@1.1.0 - new cordova release; minor to node package
cordova@3.4.0@1.1.1 - patch to node package
I hope this helps t
gt; cordova@3.2.0@0.2.0 - new cordova release; no node package changes
> cordova@3.2.0@0.2.1 - patch to node package
> cordova@3.3.0@0.2.2 - new cordova release; patch to node package
> cordova@3.3.0@0.3.0 - minor to node package
> cordova@3.3.0@1.0.0 - major to node package (non-backwards compatible api
> change)
> cordova@3.4.0@1.1.0 - new cordova release; minor to node package
> cordova@3.4.0@1.1.1 - patch to node package
>
> I hope this helps to improve the cordova-cli versioning habit.
>
> Cheers!
> Michael
>
ova@3.3.0@1.0.0 - major to node package (non-backwards compatible api
change)
cordova@3.4.0@1.1.0 - new cordova release; minor to node package
cordova@3.4.0@1.1.1 - patch to node package
I hope this helps to improve the cordova-cli versioning habit.
Cheers!
Michael
Noted in https://issues.apache.org/jira/browse/CB-2163
On 3/26/13 11:34 AM, "Braden Shepherdson" wrote:
>+1 to having ~/.cordova/thing/name/version. I know we name our releases
>foo-version, but this is an unambiguous split on a character that isn't
>legal in plugin names.
>
>Braden
>
>
>On Tue,
+1 to having ~/.cordova/thing/name/version. I know we name our releases
foo-version, but this is an unambiguous split on a character that isn't
legal in plugin names.
Braden
On Tue, Mar 26, 2013 at 1:34 PM, Michael Brooks wrote:
> >
> > ~/.cordova///
>
>
> I originally wrote this but expected
>
> ~/.cordova///
I originally wrote this but expected some backlash on breaking our
- convention. I agree, it makes the tool parsing easier.
One thing, though: cordova-cli currently runs up the file tree searching
> for '.cordova' to identify a cordova-cli-generated project root (like
> git).
Yep, on it, and agree.
One thing, though: cordova-cli currently runs up the file tree searching
for '.cordova' to identify a cordova-cli-generated project root (like
git). Can we rename the cache folder to something other than .cordova?
.cordovalibs or something?
On 3/26/13 10:22 AM, "Brian LeRou
Ok. I really like Mike's proposal. Think we should do this. Its solves
most of our woe. Slight caveat that I would like the cache to be in
the format of:
~/.cordova///
(To prevent weird string splitting logic/bugs emerging.)
Fil: can you backlog this? I think it should come AFTER we finish
fixi
With respect to the lazy-loading suggestion, I know Brian has raised the
offline scenario on a previous thread.
At install time of the CLI (`npm install -g cordova`), we can lazy-load all
platforms and sample app(s) for a given version.
At install time of the CLI as a library (`npm install cordov
Really like this. It a) slims down the cli tools by lazy loading the
libraries as they are needed and b) solves the upgrade/downgrade story,
since eventually you'll be able to simply change the version of the
cordova npm dependency at a project-level.
The only "downside" (not really) is that every
+1 to locking the CLI to a version
+1 to the Grunt vision
However, I'd like to propose a different approach to the CLI versioning and
it can also solve the `create` command issue to help move towards a dumb
global `cordova`.
## Cordova-CLI
- npm version is still associated with a Cordova distrib
As Tommay pointed out, you need to create the cordova project structure in
the first place with some manner of tool..
On 3/22/13 11:58 AM, "tommy-carlos Williams" wrote:
>I don't have much to add except that I really like this about Grunt.
>
>However, it would get "interesting" with Cordova sinc
Maybe a good first stab at this (and maybe this works already), is to
ensure multiple versions of CLI can be installed at the same time.
e.g.
/usr/loca/cordova-cli/2.4
/usr/loca/cordova-cli/2.5
/usr/loca/cordova-cli/2.6
The global symlink in /usr/local/bin would point to the latest, but your
pro
I don't have much to add except that I really like this about Grunt.
However, it would get "interesting" with Cordova since the global is what
creates a project in the first place. I still think it could work and have the
global only responsible for creating dirs and setting up package.json stu
Right now the global executable is version locked to a Cordova
release. If you have a project running 2.5 you are required to have
Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you need to
downgrade (not really but you would to be safe).
In Grunt .4 the global executable is dumb. It jus
17 matches
Mail list logo
