Resolved for iOS. sent PR for cordova-coho
On Fri, Aug 29, 2014 at 11:51 AM, Steven Gill wrote:
> I created one now. https://issues.apache.org/jira/browse/CB-7432
>
>
>
>
> On Thu, Aug 28, 2014 at 10:17 PM, Gorkem Ercan
> wrote:
>
>> Is there a JIRA to follow up on this change?
>> --
>> Gorkem
>
I created one now. https://issues.apache.org/jira/browse/CB-7432
On Thu, Aug 28, 2014 at 10:17 PM, Gorkem Ercan
wrote:
> Is there a JIRA to follow up on this change?
> --
> Gorkem
>
>
> On Fri, Aug 29, 2014 at 3:16 AM, Steven Gill
> wrote:
>
> > Just a quick update to this.
> >
> > Coho now
Is there a JIRA to follow up on this change?
--
Gorkem
On Fri, Aug 29, 2014 at 3:16 AM, Steven Gill wrote:
> Just a quick update to this.
>
> Coho now updates the version script for the following platforms:
> Android
> Amazon-fireos
> Ubuntu
> Firefoxos
> Blackberry
>
> If coho is being used fo
Just a quick update to this.
Coho now updates the version script for the following platforms:
Android
Amazon-fireos
Ubuntu
Firefoxos
Blackberry
If coho is being used for releases, I think this is the way to go. iOS,
windows and wp8 are the only remaining ones.
Line to edit in coho:
https://githu
> On Aug 14, 2014, at 4:09 AM, Ian Clelland wrote:
>
> +1 -- there's little value in trying to derive something at runtime that
> should just be hard-coded. (And even if we didn't have coho, we could set
> it manually without too much effort. :) )
If we remember to.
+0
>
>
>> On Wed, Aug
+1 -- there's little value in trying to derive something at runtime that
should just be hard-coded. (And even if we didn't have coho, we could set
it manually without too much effort. :) )
On Wed, Aug 13, 2014 at 8:28 PM, Steven Gill wrote:
> Using android's method of doing this doesn't seem so
Using android's method of doing this doesn't seem so bad to me.
Version script has hard coded value that coho sets when doing a release.
Seems to be working fine as long as coho is used for releasing.
Thoughts?
On Wed, Aug 13, 2014 at 1:44 PM, Carlos Santana
wrote:
> I think having the ios pl
I think having the ios platform scripts in nodejs have a side benefit of
being able to create ios platform on Linux and Windows.
IBM Worklight customers use this use case, where they create ios cordova
app, and in Windows or Linux they use it for preview with MBS a tool
similar to Ripple, and gene
Believe me, I want to go all node -- but all in for all scripts --
which we don't have time to do yet (maybe 4.0?).
But seeing that it's just replacing the contents of the current bash
script with python code, it's the path of least resistance, and path
of least potential conflict imo. No one will
Shaz, that's technically true, but how many users actually use that path
these days?
I thought the last stats overwhelmingly suggest our users are drinking the
kool-aid and using cli, node, etc.
On Tue, Aug 12, 2014 at 4:19 PM, Shazron wrote:
> Not if they are installed manually. It's not wort
On Tue, Aug 12, 2014 at 4:18 PM, Lorin Beer wrote:
> the version scripts are just about the only thing about the platform
> scripts that are simple enough to rewrite trivially.
Which is why the Android version scripts are literally
console.log("whatever_the_version_was_when_we_updated_this_fil
yeah, do what is easiest, and adds the least dependencies.
My point was just that I wonder if non-CLI paths still exist. #offtopic ...
@purplecabbage
risingj.com
On Tue, Aug 12, 2014 at 1:19 PM, Shazron wrote:
> Not if they are installed manually. It's not worth having some
> dependency just t
Not if they are installed manually. It's not worth having some
dependency just to read a version, that's nuts.
On Tue, Aug 12, 2014 at 1:15 PM, Jesse wrote:
> the non-cordova cli path depends on node to install/uninstall plugins
>
> @purplecabbage
> risingj.com
>
>
> On Tue, Aug 12, 2014 at 1:08
the version scripts are just about the only thing about the platform
scripts that are simple enough to rewrite trivially. Leveraging a
rewrite/refactor of the version script into a total rewrite of platform
level scripts == 'lulz'
On Tue, Aug 12, 2014 at 1:15 PM, Jesse wrote:
> the non-cordova
the non-cordova cli path depends on node to install/uninstall plugins
@purplecabbage
risingj.com
On Tue, Aug 12, 2014 at 1:08 PM, Shazron wrote:
> Of course I considered nodejs, but no, this is for the non-cordova CLI
> path, which does not need another dependency.
>
> On Tue, Aug 12, 2014 at
Of course I considered nodejs, but no, this is for the non-cordova CLI
path, which does not need another dependency.
On Tue, Aug 12, 2014 at 11:52 AM, Jesse wrote:
> Yeah, if you are going to replace bash, replace it with nodejs!
>
>
> @purplecabbage
> risingj.com
>
>
> On Tue, Aug 12, 2014 at 11
But what should we store in the shed?
On Aug 12, 2014 12:33 PM, "Brian LeRoux" wrote:
> In another life I'd love to paint that shed.
>
>
>
> On Tue, Aug 12, 2014 at 12:25 PM, Jesse wrote:
>
> > Michal, exactly!
> > Brian, hilarious, I was implying rewrite ALL the platform scripts in
> nodejs
> >
In another life I'd love to paint that shed.
On Tue, Aug 12, 2014 at 12:25 PM, Jesse wrote:
> Michal, exactly!
> Brian, hilarious, I was implying rewrite ALL the platform scripts in nodejs
> ... as was recently done for cordova-windows. May be more work than it is
> worth though.
>
> @purpleca
=)
I'm a bit of a bash nerd but in seriousness we have many Windows users so
keeping it pure Node is probably the best idea.
On Tue, Aug 12, 2014 at 12:17 PM, Myles Borins wrote:
> A, I forgot to shim my path with a sense of humor... Oops!
> On Aug 12, 2014 12:16 PM, "Brian LeRoux" wrote
Michal, exactly!
Brian, hilarious, I was implying rewrite ALL the platform scripts in nodejs
... as was recently done for cordova-windows. May be more work than it is
worth though.
@purplecabbage
risingj.com
On Tue, Aug 12, 2014 at 12:17 PM, Myles Borins wrote:
> A, I forgot to shim my pat
A, I forgot to shim my path with a sense of humor... Oops!
On Aug 12, 2014 12:16 PM, "Brian LeRoux" wrote:
> main benefit was humor though an argument could be made for other ones ;)
>
>
>
> On Tue, Aug 12, 2014 at 12:06 PM, Myles Borins wrote:
>
> > Brian, would there be any benefit to usin
main benefit was humor though an argument could be made for other ones ;)
On Tue, Aug 12, 2014 at 12:06 PM, Myles Borins wrote:
> Brian, would there be any benefit to using bash to call node rather than a
> script that started with #! /bin/env node?
> On Aug 12, 2014 12:01 PM, "Brian LeRoux"
Brian, would there be any benefit to using bash to call node rather than a
script that started with #! /bin/env node?
On Aug 12, 2014 12:01 PM, "Brian LeRoux" wrote:
> OR BOTH
>
> #!/bin/sh
> node -e 'console.log(require("./package.json").version)'
>
>
> On Tue, Aug 12, 2014 at 11:52 AM, Jesse w
..re reading your email, I think thats exactly what you mean and also
suggested the same solution :P alrighty!
On Tue, Aug 12, 2014 at 3:00 PM, Michal Mocny wrote:
> Jesse what did you mean about output projects and package.json?
>
> Do you mean the result of running cordova create / ./create
OR BOTH
#!/bin/sh
node -e 'console.log(require("./package.json").version)'
On Tue, Aug 12, 2014 at 11:52 AM, Jesse wrote:
> Yeah, if you are going to replace bash, replace it with nodejs!
>
>
> @purplecabbage
> risingj.com
>
>
> On Tue, Aug 12, 2014 at 11:48 AM, Myles Borins wrote:
>
> > Have
Jesse what did you mean about output projects and package.json?
Do you mean the result of running cordova create / ./create script? If the
intention is to know what version of the platform was used to create the
project, then we can either copy the source package.json to the root of the
platform
Yeah, if you are going to replace bash, replace it with nodejs!
@purplecabbage
risingj.com
On Tue, Aug 12, 2014 at 11:48 AM, Myles Borins wrote:
> Have you considered writing a small node script to pass the json? This
> would make it as simple as requiring in the package json an piping the
>
Have you considered writing a small node script to pass the json? This
would make it as simple as requiring in the package json an piping the
relevant info to stdout
On Aug 12, 2014 11:47 AM, "Shazron" wrote:
> Yeah I value life and my sanity - I'll probably replace the bash
> script with python
Yeah I value life and my sanity - I'll probably replace the bash
script with python
On Tue, Aug 12, 2014 at 11:40 AM, Lorin Beer wrote:
> one source for version information is better
>
> although parsing json with bash scripts seems janky
>
>
> On Tue, Aug 12, 2014 at 11:31 AM, Jesse wrote:
>
>>
one source for version information is better
although parsing json with bash scripts seems janky
On Tue, Aug 12, 2014 at 11:31 AM, Jesse wrote:
> I think it still needs to exist in an output project ... which is not
> (yet?) an npm project, and so does not have a package.json.
>
> The individu
Heh now I have to read up on how to parse json using bash O_o
On Tue, Aug 12, 2014 at 11:30 AM, Ian Clelland wrote:
> I presume that the alternative would be for the version scripts to parse
> package.json instead. I think that Android used to work the same way, but
> now its version script just
For iOS, the only file I can see that depends on this is:
1.
https://github.com/apache/cordova-ios/blob/master/bin/templates/scripts/cordova/version
Not sure of the alternative.
This references it but can be removed:
https://github.com/apache/cordova-ios/blob/master/bin/create
On Tue, Aug 12,
I think it still needs to exist in an output project ... which is not
(yet?) an npm project, and so does not have a package.json.
The individual platform repos can get rid of it, they will just need to
modify the way they `create` new projects to read the value from
package.json and output it to N
I presume that the alternative would be for the version scripts to parse
package.json instead. I think that Android used to work the same way, but
now its version script just reports a hard-coded number (which coho
updates).
As long as the package.json files are included in the release artifacts,
Most of our repos have a package.json. It keeps track of versions. I think
we should work towards removing the VERSION files from the repos we can.
Thoughts?
This would require some changes to coho so it doesn't try to update the
version file when doing releases.
35 matches
Mail list logo
