Re: two new repos for cordova
I'll add the components in JIRA On Mon, Sep 23, 2013 at 3:44 AM, Brian LeRoux wrote: > https://issues.apache.org/jira/browse/INFRA-6778 > > fyi >
Re: 3.1 Release
On Mon, Sep 23, 2013 at 2:58 PM, Andrew Grieve wrote: > Plugins are not tagged nor branched along with platforms. They are releases > completely independently. > > Commit to the "dev" branch always. AND FOREVER!11!!eleventyone!!! Seriously, can't we have a stable branch instead? Having the dev branch for dev on plugins and having master for dev on platforms is stupid and makes it harder to do work.
Re: 3.1 Release
Plugins are not tagged nor branched along with platforms. They are releases completely independently. Commit to the "dev" branch always. For how to do a plugin release (aka merge dev into master, see https://wiki.apache.org/cordova/StepsForPluginRelease). Anis just added a branch for pushing them to the cordova registry, where the only difference is removing the url= attribute from tags. That step should be added to the release page. On Mon, Sep 23, 2013 at 4:37 PM, Jesse wrote: > I have a small change for Windows 8 that I need to apply to all the core > plugins. > Which branch should I work from, and which should I push to? > > @purplecabbage > risingj.com > > > On Mon, Sep 23, 2013 at 9:39 AM, Joe Bowser wrote: > > > So, what are the plugins being versioned at? 3.x? 1.x? > > > > I'm asking because the plugins are tagged with the 3.0.0 release, so > > it makes sense for them to start there. > > > > On Mon, Sep 23, 2013 at 6:40 AM, Braden Shepherdson > > > wrote: > > > I don't think we want the Cordova version (3.1.0) getting tagged in > > > plugins. I should think we should merge dev to master and then tag it > > with > > > the plugin's own version number, not Cordova versions. Put another way, > > > it's only a coincidence that this plugin release happens to be near the > > > Cordova 3.1.0 release. > > > > > > Braden > > > > > > > > > On Sat, Sep 21, 2013 at 7:01 AM, Anis KADRI > > wrote: > > > > > >> Jira issue is: https://issues.apache.org/jira/browse/CB-4889 > > >> > > >> On Sat, Sep 21, 2013 at 12:59 PM, Anis KADRI > > wrote: > > >> > This is what I've done. Hopefully I didn't mess up because I haven't > > >> > really followed the master/dev debate. > > >> > > > >> > For each plugin: > > >> > - I created a branch and named it 3.1.0 > > >> > - I pulled from origin dev > > >> > - I renamed the id from org.apache.cordova.core.* to > > org.apache.cordova.* > > >> > - I renamed the version from x.x.xdev to x.x.x > > >> > - I changed the dependency from URL to id where applicable (I > believe > > >> > it was only file-transfer and media-capture) > > >> > - I published the plugin to the registry > > >> > - I unpublished the old plugin from the registry. > > >> > > > >> > The docs were actually already reflecting IDs without 'core' in them > > >> > so I didn't update them. > > >> > > > >> > The process (once we figure out what to do about those 3.0.0 users) > > >> > should be in the future. > > >> > - Work on master > > >> > - Tag version > > >> > - Publish that version > > >> > > > >> > I left master untouched for all plugins so 3.0.0 users should not > have > > >> > any issues. > > >> > > > >> > -a > > >> > > > >> > On Sat, Sep 21, 2013 at 4:01 AM, Andrew Grieve < > agri...@chromium.org> > > >> wrote: > > >> >> Sorry for being silent today. I ended up not having much time to > work > > >> today > > >> >> :(. Mostly what I got done is more thinking about how to go about > > >> things :P. > > >> >> > > >> >> That said, Braden did manage to take care of RC1 of CLI! Thanks > > Braden! > > >> ( > > >> >> https://issues.apache.org/jira/browse/CB-4837). To get it: > > >> >> > > >> >> npm install -g cordova@3.0.10 > > >> >> > > >> >> With the RC, doing a "cordova platform add" will add the rc1 > > platform, > > >> and > > >> >> doing a "cordova platform update" will update an existing platform > to > > >> rc1. > > >> >> > > >> >> I think we should hold off on a blog post for it until we update > the > > >> >> plugins in the registry (and at the same time remove the .core > > part). If > > >> >> someone else wants to take that on, that'd be awesome. Otherwise I > > will > > >> get > > >> >> to it on Sunday while I'm in Amsterdam :). > > >> >> > > >> >> One revelation I had about the registry: > > >> >> I think we should *not* remove the url= line from FileTransfer's > > >> >> tag for a little while. This will mean that even when > > >> >> FileTransfer comes from the registry, its dependency will come > > straight > > >> >> from the URL. The copy in the registry and the copy in git are the > > >> same, so > > >> >> this should be fine. If we *did* remove the url right away, then > > people > > >> >> using the 3.0 tools and following the 3.0 instructions would break. > > >> >> > > >> >> New New timeline: > > >> >> ASAP - Upload rc1 of cordova-docs > > >> >> Sunday/Monday - Plugin release + Uploading plugins to registry > > >> >> Monday - Blog post announcing RC1 > > >> >> Rest of week: Test upgrade process, Test the registry out, Make > sure > > >> docs > > >> >> are good, Test download tracking of the registry > > >> >> Following Monday (ish): Final Release > > >> >> > > >> >> In this revision, I push back the final release even more because I > > >> realize > > >> >> many of us will be travelling back from AMS. > > >> >> > > >> >> On Fri, Sep 20, 2013 at 4:49 PM, Ryan Stewart > > >> wrote: > > >> >> > > >> >>> Ahh, thanks for the info. Any ETA on the updated plugins? > > >> >>> > > >> >>> =Ryan > > >>
Re: 3.1 Release
I have a small change for Windows 8 that I need to apply to all the core plugins. Which branch should I work from, and which should I push to? @purplecabbage risingj.com On Mon, Sep 23, 2013 at 9:39 AM, Joe Bowser wrote: > So, what are the plugins being versioned at? 3.x? 1.x? > > I'm asking because the plugins are tagged with the 3.0.0 release, so > it makes sense for them to start there. > > On Mon, Sep 23, 2013 at 6:40 AM, Braden Shepherdson > wrote: > > I don't think we want the Cordova version (3.1.0) getting tagged in > > plugins. I should think we should merge dev to master and then tag it > with > > the plugin's own version number, not Cordova versions. Put another way, > > it's only a coincidence that this plugin release happens to be near the > > Cordova 3.1.0 release. > > > > Braden > > > > > > On Sat, Sep 21, 2013 at 7:01 AM, Anis KADRI > wrote: > > > >> Jira issue is: https://issues.apache.org/jira/browse/CB-4889 > >> > >> On Sat, Sep 21, 2013 at 12:59 PM, Anis KADRI > wrote: > >> > This is what I've done. Hopefully I didn't mess up because I haven't > >> > really followed the master/dev debate. > >> > > >> > For each plugin: > >> > - I created a branch and named it 3.1.0 > >> > - I pulled from origin dev > >> > - I renamed the id from org.apache.cordova.core.* to > org.apache.cordova.* > >> > - I renamed the version from x.x.xdev to x.x.x > >> > - I changed the dependency from URL to id where applicable (I believe > >> > it was only file-transfer and media-capture) > >> > - I published the plugin to the registry > >> > - I unpublished the old plugin from the registry. > >> > > >> > The docs were actually already reflecting IDs without 'core' in them > >> > so I didn't update them. > >> > > >> > The process (once we figure out what to do about those 3.0.0 users) > >> > should be in the future. > >> > - Work on master > >> > - Tag version > >> > - Publish that version > >> > > >> > I left master untouched for all plugins so 3.0.0 users should not have > >> > any issues. > >> > > >> > -a > >> > > >> > On Sat, Sep 21, 2013 at 4:01 AM, Andrew Grieve > >> wrote: > >> >> Sorry for being silent today. I ended up not having much time to work > >> today > >> >> :(. Mostly what I got done is more thinking about how to go about > >> things :P. > >> >> > >> >> That said, Braden did manage to take care of RC1 of CLI! Thanks > Braden! > >> ( > >> >> https://issues.apache.org/jira/browse/CB-4837). To get it: > >> >> > >> >> npm install -g cordova@3.0.10 > >> >> > >> >> With the RC, doing a "cordova platform add" will add the rc1 > platform, > >> and > >> >> doing a "cordova platform update" will update an existing platform to > >> rc1. > >> >> > >> >> I think we should hold off on a blog post for it until we update the > >> >> plugins in the registry (and at the same time remove the .core > part). If > >> >> someone else wants to take that on, that'd be awesome. Otherwise I > will > >> get > >> >> to it on Sunday while I'm in Amsterdam :). > >> >> > >> >> One revelation I had about the registry: > >> >> I think we should *not* remove the url= line from FileTransfer's > >> >> tag for a little while. This will mean that even when > >> >> FileTransfer comes from the registry, its dependency will come > straight > >> >> from the URL. The copy in the registry and the copy in git are the > >> same, so > >> >> this should be fine. If we *did* remove the url right away, then > people > >> >> using the 3.0 tools and following the 3.0 instructions would break. > >> >> > >> >> New New timeline: > >> >> ASAP - Upload rc1 of cordova-docs > >> >> Sunday/Monday - Plugin release + Uploading plugins to registry > >> >> Monday - Blog post announcing RC1 > >> >> Rest of week: Test upgrade process, Test the registry out, Make sure > >> docs > >> >> are good, Test download tracking of the registry > >> >> Following Monday (ish): Final Release > >> >> > >> >> In this revision, I push back the final release even more because I > >> realize > >> >> many of us will be travelling back from AMS. > >> >> > >> >> On Fri, Sep 20, 2013 at 4:49 PM, Ryan Stewart > >> wrote: > >> >> > >> >>> Ahh, thanks for the info. Any ETA on the updated plugins? > >> >>> > >> >>> =Ryan > >> >>> > >> >>> On 9/20/13 1:46 PM, "Michal Mocny" wrote: > >> >>> > >> >>> >I think Braden is supposed to get an RC of the cli out today. I'm > >> told > >> >>> >this this may not included updated plugins yet until later, though. > >> >>> > > >> >>> > > >> >>> >On Fri, Sep 20, 2013 at 4:19 PM, Ryan Stewart > >> wrote: > >> >>> > > >> >>> >> Is the RC still on track to get tagged today? > >> >>> >> > >> >>> >> I'm working on the PhoneGap-CLI and want to also release an RC > >> version > >> >>> >>of > >> >>> >> that when you guys have tagged. > >> >>> >> > >> >>> >> =Ryan > >> >>> >> > >> >>> >> On 9/20/13 1:01 PM, "Steven Gill" > wrote: > >> >>> >> > >> >>> >> >I think since it has taken longer than expected to get the RC > >> tagged, > >> >>> >>the > >> >
Re: Major refactoring of Plugman and CLI
Whoops, I forgot to mention, I created and pushed a cordova-3.1.x branch of
both tools before merging this; fixes for the 3.1.0 release should be in
there. I don't intend to launch the refactored code to NPM until we've had
at least a week of trying it out.
Braden
On Mon, Sep 23, 2013 at 2:08 PM, Braden Shepherdson wrote:
> tl;dr: Plugman and CLI now uses Q.js[1] Promises internally instead of
> callbacks. This has significantly clarified and shortened the code. The
> public API (plugman.fetch, cordova.platform, etc.) HAVE NOT changed!
>
> If you use CLI on the command line, nothing has changed.
>
> If you downstream CLI and/or Plugman, but use cordova.foo and plugman.foo,
> nothing has changed (except possibly that a few calls are a bit more async
> than before, so code that cheats and pretends they're sync might fail now).
>
> If you downstream either one, but require internal modules like fetch.js
> or platform.js directly, you should stop doing that and use plugman.fetch
> etc. instead. If you want to continue calling them directly, you'll need to
> port to use promises.
>
> If you've been working on Plugman or CLI and I just broke everything, feel
> free to yell at me on IRC (#cordova, shepheb) or Gtalk (braden at google
> dot com) or email. It's not hard to port things to handle promises (see
> below), and their basic use is not hard to understand (see the tutorial[1]).
>
> If you really do need to port something, and you used to do a function
> call like this:
>
> whateverFunc(args..., function(err){
> if (err) {
> foo
> } else {
> bar
> }
> });
>
> the correct call is now:
>
> whateverFunc(args...).done(function() {
> bar
> }, function(err) {
> foo
> });
>
>
> [1] Q.js tutorial at https://github.com/kriskowal/q
>
>
Major refactoring of Plugman and CLI
tl;dr: Plugman and CLI now uses Q.js[1] Promises internally instead of
callbacks. This has significantly clarified and shortened the code. The
public API (plugman.fetch, cordova.platform, etc.) HAVE NOT changed!
If you use CLI on the command line, nothing has changed.
If you downstream CLI and/or Plugman, but use cordova.foo and plugman.foo,
nothing has changed (except possibly that a few calls are a bit more async
than before, so code that cheats and pretends they're sync might fail now).
If you downstream either one, but require internal modules like fetch.js or
platform.js directly, you should stop doing that and use plugman.fetch etc.
instead. If you want to continue calling them directly, you'll need to port
to use promises.
If you've been working on Plugman or CLI and I just broke everything, feel
free to yell at me on IRC (#cordova, shepheb) or Gtalk (braden at google
dot com) or email. It's not hard to port things to handle promises (see
below), and their basic use is not hard to understand (see the tutorial[1]).
If you really do need to port something, and you used to do a function call
like this:
whateverFunc(args..., function(err){
if (err) {
foo
} else {
bar
}
});
the correct call is now:
whateverFunc(args...).done(function() {
bar
}, function(err) {
foo
});
[1] Q.js tutorial at https://github.com/kriskowal/q
Re: About Cordova, Adobe and W3C ?
Myself and Mike Brooks keep tabs on sysapps, dap, webapps, csswg, and random others too. On Sep 23, 2013 4:34 PM, "Michal Mocny" wrote: > Fil Maj is on the sysapps WG, I think. > > -Michal > > > On Mon, Sep 23, 2013 at 10:04 AM, Plaquette, Paul > wrote: > > > Hi Folks, > > > > Are they people among us involved in W3C Working groups? > > > > Cordially , > > Paul > > > > ~~~ > > > > Paul Plaquette, > > Senior Software Engineer > > Intel Corporation SAS * > > * > > *SSG/OTC: Open Source Technology Center* > > France, Montpellier > > >
Re: 3.1 Release
So, what are the plugins being versioned at? 3.x? 1.x? I'm asking because the plugins are tagged with the 3.0.0 release, so it makes sense for them to start there. On Mon, Sep 23, 2013 at 6:40 AM, Braden Shepherdson wrote: > I don't think we want the Cordova version (3.1.0) getting tagged in > plugins. I should think we should merge dev to master and then tag it with > the plugin's own version number, not Cordova versions. Put another way, > it's only a coincidence that this plugin release happens to be near the > Cordova 3.1.0 release. > > Braden > > > On Sat, Sep 21, 2013 at 7:01 AM, Anis KADRI wrote: > >> Jira issue is: https://issues.apache.org/jira/browse/CB-4889 >> >> On Sat, Sep 21, 2013 at 12:59 PM, Anis KADRI wrote: >> > This is what I've done. Hopefully I didn't mess up because I haven't >> > really followed the master/dev debate. >> > >> > For each plugin: >> > - I created a branch and named it 3.1.0 >> > - I pulled from origin dev >> > - I renamed the id from org.apache.cordova.core.* to org.apache.cordova.* >> > - I renamed the version from x.x.xdev to x.x.x >> > - I changed the dependency from URL to id where applicable (I believe >> > it was only file-transfer and media-capture) >> > - I published the plugin to the registry >> > - I unpublished the old plugin from the registry. >> > >> > The docs were actually already reflecting IDs without 'core' in them >> > so I didn't update them. >> > >> > The process (once we figure out what to do about those 3.0.0 users) >> > should be in the future. >> > - Work on master >> > - Tag version >> > - Publish that version >> > >> > I left master untouched for all plugins so 3.0.0 users should not have >> > any issues. >> > >> > -a >> > >> > On Sat, Sep 21, 2013 at 4:01 AM, Andrew Grieve >> wrote: >> >> Sorry for being silent today. I ended up not having much time to work >> today >> >> :(. Mostly what I got done is more thinking about how to go about >> things :P. >> >> >> >> That said, Braden did manage to take care of RC1 of CLI! Thanks Braden! >> ( >> >> https://issues.apache.org/jira/browse/CB-4837). To get it: >> >> >> >> npm install -g cordova@3.0.10 >> >> >> >> With the RC, doing a "cordova platform add" will add the rc1 platform, >> and >> >> doing a "cordova platform update" will update an existing platform to >> rc1. >> >> >> >> I think we should hold off on a blog post for it until we update the >> >> plugins in the registry (and at the same time remove the .core part). If >> >> someone else wants to take that on, that'd be awesome. Otherwise I will >> get >> >> to it on Sunday while I'm in Amsterdam :). >> >> >> >> One revelation I had about the registry: >> >> I think we should *not* remove the url= line from FileTransfer's >> >> tag for a little while. This will mean that even when >> >> FileTransfer comes from the registry, its dependency will come straight >> >> from the URL. The copy in the registry and the copy in git are the >> same, so >> >> this should be fine. If we *did* remove the url right away, then people >> >> using the 3.0 tools and following the 3.0 instructions would break. >> >> >> >> New New timeline: >> >> ASAP - Upload rc1 of cordova-docs >> >> Sunday/Monday - Plugin release + Uploading plugins to registry >> >> Monday - Blog post announcing RC1 >> >> Rest of week: Test upgrade process, Test the registry out, Make sure >> docs >> >> are good, Test download tracking of the registry >> >> Following Monday (ish): Final Release >> >> >> >> In this revision, I push back the final release even more because I >> realize >> >> many of us will be travelling back from AMS. >> >> >> >> On Fri, Sep 20, 2013 at 4:49 PM, Ryan Stewart >> wrote: >> >> >> >>> Ahh, thanks for the info. Any ETA on the updated plugins? >> >>> >> >>> =Ryan >> >>> >> >>> On 9/20/13 1:46 PM, "Michal Mocny" wrote: >> >>> >> >>> >I think Braden is supposed to get an RC of the cli out today. I'm >> told >> >>> >this this may not included updated plugins yet until later, though. >> >>> > >> >>> > >> >>> >On Fri, Sep 20, 2013 at 4:19 PM, Ryan Stewart >> wrote: >> >>> > >> >>> >> Is the RC still on track to get tagged today? >> >>> >> >> >>> >> I'm working on the PhoneGap-CLI and want to also release an RC >> version >> >>> >>of >> >>> >> that when you guys have tagged. >> >>> >> >> >>> >> =Ryan >> >>> >> >> >>> >> On 9/20/13 1:01 PM, "Steven Gill" wrote: >> >>> >> >> >>> >> >I think since it has taken longer than expected to get the RC >> tagged, >> >>> >>the >> >>> >> >final release has been push till thursday to allow more time to >> test. >> >>> >>Is >> >>> >> >this correct? >> >>> >> > >> >>> >> > >> >>> >> >On Fri, Sep 20, 2013 at 12:58 PM, Marcel Kinard < >> cmarc...@gmail.com> >> >>> >> >wrote: >> >>> >> > >> >>> >> >> I'm confused about the date for 3.1.0 final release. These two >> posts >> >>> >> >>don't >> >>> >> >> match. >> >>> >> >> >> >>> >> >> On Sep 19, 2013, at 11:27 PM, Andrew Grieve < >> agri...@chromium.org> >> >>> >> >>wrote: >> >
Re: What's your daily workflow for cordova development?
It could be, and there's even a plugin add --link option. BUT, there's a major caveat here: Changes to plugin.xml, native code, and possibly other parts, won't be updated on cordova prepare, but only on cordova plugin add. So you'd have to plugin rm+add on most changes anyway, so there's little advantage to linking. Braden On Mon, Sep 23, 2013 at 10:33 AM, Jamie Munro wrote: > Could a plugin that is in development be symlinked into the plugins folder > of the project it is being developed for? > > Robert (Jamie) Munro > > > On 20 September 2013 17:38, Brian LeRoux wrote: > > > Agree you will certainly arrive at the ideal solution by iterating from > the > > less-than-ideal solution. That is not a reason to not start breaking > stuff > > though. > > > > > > On Fri, Sep 20, 2013 at 5:31 PM, Michal Mocny > wrote: > > > > > Ugh, unfortunately Braden is right. Still, I think that means we can > > move > > > forward with the plan to make "plugman create" work anywhere and > "cordova > > > plugin create" only work inside of a workspace, but don't implement the > > > latter until its actually feasible to make edits to plugins inside a > > > workspace in some sane fashion. > > > > > > Not supporting cordova plugin create from a global context leaves us > open > > > to doing the right thing in the future, I think. > > > > > > -Michal > > > > > > > > > On Fri, Sep 20, 2013 at 7:53 AM, Braden Shepherdson < > bra...@chromium.org > > > >wrote: > > > > > > > I would caution against developing a plugin inside a cordova-cli > > > workspace. > > > > The nature of the install vs. prepare divide is that any changes to > > > native > > > > code require reinstalling. That's confusing for developers, so I > would > > > > recommend that the best way to develop a plugin using CLI is to > plugman > > > > create elsewhere, and then install that plugin into a CLI workspace > for > > > > testing. Then when you make a change to the plugin at its top-level > > > > location, you uninstall and reinstall it. > > > > > > > > I recognize that this flow is less than ideal, and I'd like to > improve > > it > > > > in the long term, but in the meantime it would be a bad idea to keep > a > > > > plugin's canonical location inside plugins/. > > > > > > > > Braden > > > > > > > > > > > > On Fri, Sep 20, 2013 at 10:16 AM, Lucas Holmquist < > lholm...@redhat.com > > > > >wrote: > > > > > > > > > i always forget about plugman > > > > > On Sep 20, 2013, at 9:57 AM, Michal Mocny > > wrote: > > > > > > > > > > > plugman create could be used outside of a project, and cordova > > plugin > > > > > > create should be used only inside of a project? > > > > > > > > > > > > All other cordova commands must be used inside a project (except > > the > > > > > > "create" entry point), and if we decide to ship the plugin > > templates > > > > with > > > > > > platforms, and/or decide to make the global cordova command just > a > > > > > > grunt-cli like thing, etc etc, then I would worry about adding > uses > > > for > > > > > > cordova command in some global context. > > > > > > > > > > > > > > > > > > On Fri, Sep 20, 2013 at 6:42 AM, Lucas Holmquist < > > > lholm...@redhat.com > > > > > >wrote: > > > > > > > > > > > >> So currently when doing > > > > > >> > > > > > >> $ cordova plugin …. > > > > > >> > > > > > >> it fails if you are not in a cordova project. > > > > > >> > > > > > >> but > > > > > >> > > > > > >> $ cordova plugin create > > > > > >> > > > > > >> might not be used inside a project( i think it shouldn't be used > > > > inside > > > > > a > > > > > >> project at all, but i can be convinced otherwise ) > > > > > >> > > > > > >> > > > > > >> On Sep 4, 2013, at 10:46 PM, lmnbeyond > > wrote: > > > > > >> > > > > > >>> > > > > > >>> > > > > > I also think it should sub-shell to a platform script. We > > already > > > > have > > > > > a `project template` folder in each platform. We can easily > add > > a > > > > > `plugin template` as well and write a quick create_plugin > > script. > > > > > > > > > > What do you guys think of the workflow I described above ? Any > > > > > comments ? I can create jira issues for it and tackle it. > > > > > > > > > > -a > > > > > > > > > > >>> > > > > > >>> Hi Anis, > > > > > >>> > > > > > >>> I just want to confirm whether or not this is the workflow we > are > > > > > >> talking about : > > > > > >>> > > > > > >>> For a brand new plugin: > > > > > >>> > > > > > >>> $ cordova plugin create /path/to/myPlugin > > > > > >>> $ cordova plugin add /path/to/myPlugin --watch > > > > > >>> > > > > > >>> > > > > > >>> For an existing plugin: > > > > > >>> > > > > > >>> $ cordova plugin add /path/to/corePlugin --watch > > > > > >>> > > > > > >>> > > > > > >>> Although, I'm not quite clear about the complexity behind this, > > I > > > > > think > > > > > >> the above workflow is great for me! > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>>
Re: What's your daily workflow for cordova development?
Could a plugin that is in development be symlinked into the plugins folder of the project it is being developed for? Robert (Jamie) Munro On 20 September 2013 17:38, Brian LeRoux wrote: > Agree you will certainly arrive at the ideal solution by iterating from the > less-than-ideal solution. That is not a reason to not start breaking stuff > though. > > > On Fri, Sep 20, 2013 at 5:31 PM, Michal Mocny wrote: > > > Ugh, unfortunately Braden is right. Still, I think that means we can > move > > forward with the plan to make "plugman create" work anywhere and "cordova > > plugin create" only work inside of a workspace, but don't implement the > > latter until its actually feasible to make edits to plugins inside a > > workspace in some sane fashion. > > > > Not supporting cordova plugin create from a global context leaves us open > > to doing the right thing in the future, I think. > > > > -Michal > > > > > > On Fri, Sep 20, 2013 at 7:53 AM, Braden Shepherdson > >wrote: > > > > > I would caution against developing a plugin inside a cordova-cli > > workspace. > > > The nature of the install vs. prepare divide is that any changes to > > native > > > code require reinstalling. That's confusing for developers, so I would > > > recommend that the best way to develop a plugin using CLI is to plugman > > > create elsewhere, and then install that plugin into a CLI workspace for > > > testing. Then when you make a change to the plugin at its top-level > > > location, you uninstall and reinstall it. > > > > > > I recognize that this flow is less than ideal, and I'd like to improve > it > > > in the long term, but in the meantime it would be a bad idea to keep a > > > plugin's canonical location inside plugins/. > > > > > > Braden > > > > > > > > > On Fri, Sep 20, 2013 at 10:16 AM, Lucas Holmquist > > >wrote: > > > > > > > i always forget about plugman > > > > On Sep 20, 2013, at 9:57 AM, Michal Mocny > wrote: > > > > > > > > > plugman create could be used outside of a project, and cordova > plugin > > > > > create should be used only inside of a project? > > > > > > > > > > All other cordova commands must be used inside a project (except > the > > > > > "create" entry point), and if we decide to ship the plugin > templates > > > with > > > > > platforms, and/or decide to make the global cordova command just a > > > > > grunt-cli like thing, etc etc, then I would worry about adding uses > > for > > > > > cordova command in some global context. > > > > > > > > > > > > > > > On Fri, Sep 20, 2013 at 6:42 AM, Lucas Holmquist < > > lholm...@redhat.com > > > > >wrote: > > > > > > > > > >> So currently when doing > > > > >> > > > > >> $ cordova plugin …. > > > > >> > > > > >> it fails if you are not in a cordova project. > > > > >> > > > > >> but > > > > >> > > > > >> $ cordova plugin create > > > > >> > > > > >> might not be used inside a project( i think it shouldn't be used > > > inside > > > > a > > > > >> project at all, but i can be convinced otherwise ) > > > > >> > > > > >> > > > > >> On Sep 4, 2013, at 10:46 PM, lmnbeyond > wrote: > > > > >> > > > > >>> > > > > >>> > > > > I also think it should sub-shell to a platform script. We > already > > > have > > > > a `project template` folder in each platform. We can easily add > a > > > > `plugin template` as well and write a quick create_plugin > script. > > > > > > > > What do you guys think of the workflow I described above ? Any > > > > comments ? I can create jira issues for it and tackle it. > > > > > > > > -a > > > > > > > > >>> > > > > >>> Hi Anis, > > > > >>> > > > > >>> I just want to confirm whether or not this is the workflow we are > > > > >> talking about : > > > > >>> > > > > >>> For a brand new plugin: > > > > >>> > > > > >>> $ cordova plugin create /path/to/myPlugin > > > > >>> $ cordova plugin add /path/to/myPlugin --watch > > > > >>> > > > > >>> > > > > >>> For an existing plugin: > > > > >>> > > > > >>> $ cordova plugin add /path/to/corePlugin --watch > > > > >>> > > > > >>> > > > > >>> Although, I'm not quite clear about the complexity behind this, > I > > > > think > > > > >> the above workflow is great for me! > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > > >
Re: About Cordova, Adobe and W3C ?
Fil Maj is on the sysapps WG, I think. -Michal On Mon, Sep 23, 2013 at 10:04 AM, Plaquette, Paul wrote: > Hi Folks, > > Are they people among us involved in W3C Working groups? > > Cordially , > Paul > > ~~~ > > Paul Plaquette, > Senior Software Engineer > Intel Corporation SAS * > * > *SSG/OTC: Open Source Technology Center* > France, Montpellier >
About Cordova, Adobe and W3C ?
Hi Folks, Are they people among us involved in W3C Working groups? Cordially , Paul ~~~ Paul Plaquette, Senior Software Engineer Intel Corporation SAS * * *SSG/OTC: Open Source Technology Center* France, Montpellier
Re: Testing RCs in a 3.0 world
That is indeed what I did. You can't stop npm from moving the latest tag when you publish (so far as I could find out, anyway) but then you can change it back right away with npm tag. I have done this and it's confirmed by the fact that npmjs.org and npm info both show the previous 3.0.0-targeting versions as current. Braden On Sun, Sep 22, 2013 at 7:50 AM, Andrew Grieve wrote: > Yep! That's exactly what Braden did I think. > > 3.0.10 is rc1, and 3.0.9 is latest. > > > On Sun, Sep 22, 2013 at 4:14 AM, Brian LeRoux wrote: > > > According to the twitternets we can publish cordova@3.1.0-rc1 but then > > `npm > > tag cordova@3.0.123 latest` to allow for this use case w/ npm. > > > > > > > > On Wed, Sep 18, 2013 at 4:47 AM, Andrew Grieve > > wrote: > > > > > We used to post an announcement to the list announcing when an RC is > > > available, and having a download link for it. > > > > > > A download link doesn't make sense for CLI. > > > > > > I'm wondering if instead we could have: > > > > > > cordova platform add android --version=3.1.0-rc1 > > > cordova platform update android --version=3.1.0-rc1 > > > > > > Or maybe upload a version of CLI to with a "rc" tag? > > > > > > e.g.: > > > npm install -g cordova@3.1.0-rc1 > > > cordova platform add android > > > cordova platform update android > > > > > > > > > I'm thinking the --version flag would be useful to have either way, and > > > that we should do the custom npm tag for the RC. > > > > > > Thoughts? > > > > > > The other part of this is how long we let the RC bake. If we stick to > > > releasing on Monday, then that's not much time at all (but makes it in > > time > > > for PGD EU). Maybe from next release onward we have a longer RC time? > > > > > >
Re: 3.1 Release
I don't think we want the Cordova version (3.1.0) getting tagged in plugins. I should think we should merge dev to master and then tag it with the plugin's own version number, not Cordova versions. Put another way, it's only a coincidence that this plugin release happens to be near the Cordova 3.1.0 release. Braden On Sat, Sep 21, 2013 at 7:01 AM, Anis KADRI wrote: > Jira issue is: https://issues.apache.org/jira/browse/CB-4889 > > On Sat, Sep 21, 2013 at 12:59 PM, Anis KADRI wrote: > > This is what I've done. Hopefully I didn't mess up because I haven't > > really followed the master/dev debate. > > > > For each plugin: > > - I created a branch and named it 3.1.0 > > - I pulled from origin dev > > - I renamed the id from org.apache.cordova.core.* to org.apache.cordova.* > > - I renamed the version from x.x.xdev to x.x.x > > - I changed the dependency from URL to id where applicable (I believe > > it was only file-transfer and media-capture) > > - I published the plugin to the registry > > - I unpublished the old plugin from the registry. > > > > The docs were actually already reflecting IDs without 'core' in them > > so I didn't update them. > > > > The process (once we figure out what to do about those 3.0.0 users) > > should be in the future. > > - Work on master > > - Tag version > > - Publish that version > > > > I left master untouched for all plugins so 3.0.0 users should not have > > any issues. > > > > -a > > > > On Sat, Sep 21, 2013 at 4:01 AM, Andrew Grieve > wrote: > >> Sorry for being silent today. I ended up not having much time to work > today > >> :(. Mostly what I got done is more thinking about how to go about > things :P. > >> > >> That said, Braden did manage to take care of RC1 of CLI! Thanks Braden! > ( > >> https://issues.apache.org/jira/browse/CB-4837). To get it: > >> > >> npm install -g cordova@3.0.10 > >> > >> With the RC, doing a "cordova platform add" will add the rc1 platform, > and > >> doing a "cordova platform update" will update an existing platform to > rc1. > >> > >> I think we should hold off on a blog post for it until we update the > >> plugins in the registry (and at the same time remove the .core part). If > >> someone else wants to take that on, that'd be awesome. Otherwise I will > get > >> to it on Sunday while I'm in Amsterdam :). > >> > >> One revelation I had about the registry: > >> I think we should *not* remove the url= line from FileTransfer's > >> tag for a little while. This will mean that even when > >> FileTransfer comes from the registry, its dependency will come straight > >> from the URL. The copy in the registry and the copy in git are the > same, so > >> this should be fine. If we *did* remove the url right away, then people > >> using the 3.0 tools and following the 3.0 instructions would break. > >> > >> New New timeline: > >> ASAP - Upload rc1 of cordova-docs > >> Sunday/Monday - Plugin release + Uploading plugins to registry > >> Monday - Blog post announcing RC1 > >> Rest of week: Test upgrade process, Test the registry out, Make sure > docs > >> are good, Test download tracking of the registry > >> Following Monday (ish): Final Release > >> > >> In this revision, I push back the final release even more because I > realize > >> many of us will be travelling back from AMS. > >> > >> On Fri, Sep 20, 2013 at 4:49 PM, Ryan Stewart > wrote: > >> > >>> Ahh, thanks for the info. Any ETA on the updated plugins? > >>> > >>> =Ryan > >>> > >>> On 9/20/13 1:46 PM, "Michal Mocny" wrote: > >>> > >>> >I think Braden is supposed to get an RC of the cli out today. I'm > told > >>> >this this may not included updated plugins yet until later, though. > >>> > > >>> > > >>> >On Fri, Sep 20, 2013 at 4:19 PM, Ryan Stewart > wrote: > >>> > > >>> >> Is the RC still on track to get tagged today? > >>> >> > >>> >> I'm working on the PhoneGap-CLI and want to also release an RC > version > >>> >>of > >>> >> that when you guys have tagged. > >>> >> > >>> >> =Ryan > >>> >> > >>> >> On 9/20/13 1:01 PM, "Steven Gill" wrote: > >>> >> > >>> >> >I think since it has taken longer than expected to get the RC > tagged, > >>> >>the > >>> >> >final release has been push till thursday to allow more time to > test. > >>> >>Is > >>> >> >this correct? > >>> >> > > >>> >> > > >>> >> >On Fri, Sep 20, 2013 at 12:58 PM, Marcel Kinard < > cmarc...@gmail.com> > >>> >> >wrote: > >>> >> > > >>> >> >> I'm confused about the date for 3.1.0 final release. These two > posts > >>> >> >>don't > >>> >> >> match. > >>> >> >> > >>> >> >> On Sep 19, 2013, at 11:27 PM, Andrew Grieve < > agri...@chromium.org> > >>> >> >>wrote: > >>> >> >> > >>> >> >> > Next Thursday: > >>> >> >> > - If everything seems fine with RC1, release 3.1.0 final. > >>> >> >> > > >>> >> >> > >>> >> >> On Sep 10, 2013, at 3:20 PM, Andrew Grieve > > >>> >> wrote: > >>> >> >> > >>> >> >> > Monday 16th - Create release branches & tag RC of all repos > >>> >> >> > Tuesday 17th - Draft Release Blog Post (digest of changelogs)
two new repos for cordova
https://issues.apache.org/jira/browse/INFRA-6778 fyi
