https://issues.apache.org/jira/browse/INFRA-6778
fyi
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
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
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
Fil Maj is on the sysapps WG, I think.
-Michal
On Mon, Sep 23, 2013 at 10:04 AM, Plaquette, Paul
paul.plaque...@intel.comwrote:
Hi Folks,
Are they people among us involved in W3C Working groups?
Cordially ,
Paul
~~~
Paul Plaquette,
Senior Software
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 b...@brian.io wrote:
Agree you will certainly arrive at the ideal solution by iterating from the
less-than-ideal
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
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 bra...@chromium.org wrote:
I don't think we want the Cordova version (3.1.0)
Myself and Mike Brooks keep tabs on sysapps, dap, webapps, csswg, and
random others too.
On Sep 23, 2013 4:34 PM, Michal Mocny mmo...@chromium.org wrote:
Fil Maj is on the sysapps WG, I think.
-Michal
On Mon, Sep 23, 2013 at 10:04 AM, Plaquette, Paul
paul.plaque...@intel.comwrote:
Hi
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
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
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 bows...@gmail.com wrote:
So, what are the plugins being versioned at? 3.x?
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
On Mon, Sep 23, 2013 at 2:58 PM, Andrew Grieve agri...@chromium.org 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
I'll add the components in JIRA
On Mon, Sep 23, 2013 at 3:44 AM, Brian LeRoux b...@brian.io wrote:
https://issues.apache.org/jira/browse/INFRA-6778
fyi
15 matches
Mail list logo
