LGTM. There might be some reason we can't use identical flows for OSX and
iOS, but there's no point in having duplicate branches to the code if
they're the same right now. They can be split later if they diverge.
Braden
On Fri, Apr 25, 2014 at 7:17 PM, Jesse wrote:
> I think the osx repo shoul
The widget spec is deprecated. Whatever the outcome of this thread, the
argument that we should follow the Widget spec is broken. We never followed
it that closely, with several extensions and usages of a few tags not quite
as the spec intended.
I'm not particularly invested in any way of spelling
>>
> >>>>>>> +1
> >>>>>>>
> >>>>>>> On Tue, Apr 22, 2014 at 11:30 AM, Shazron
> >>> wrote:
> >>>>>>>> +1++
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
I was about to suggest exactly this. I already did part of this with the
promises refactoring; we should continue it. Mixing the arg-parsing and
actual logic is no good.
Braden
On Tue, Apr 22, 2014 at 11:26 AM, Andrew Grieve wrote:
> I think the biggest win is to do both.
>
> i.e., have an API
We originally needed the plugin releases to be on the master branch because
there was no way to have CLI/Plugman fetch from other branches. That is no
longer the case. Further, you're correct that the registry's tarballs is
the primary source now. Even if someone does have a git dependency
somewher
Sorry I missed this meeting, everyone. I was down for the count last week
with an awful head cold.
The upshots from the meeting look good to me. The only part I'm not excited
about is the idea of having a whole gaggle of cordova-lib-foo npm modules.
But I can roll with that one as long as they're
Strictly speaking it may be that a plugin could actually want to not be run
until it was require()d. In practice, I suspect most plugins either want to
clobber, merge or run, all of which will require it. So I think we're okay
with this change. That seems like an odd practice by browserify, but I
s
Cordova platforms don't map into Cordova plugins very well at all.
For npm modules, we can specify arbitrary sources, but npm has its own
ideas about where things should be installed. Do we actually want the
platforms, or at least their templates, to live in node_modules? I suppose
that's a reason
To be clear, you're suggesting that we have templates in the form of
plugins? I'm not sure that's what we really want. At least, if we install
them like regular plugins then there are several values that need to be
changed, including the directory name.
Perhaps cordova template add org.apache.cord
+1 to this concept.
I'm in to manage the tools releases, not familiar at all with the process
for the others. But I'm willing to learn enough to do it, if we're just
passing these responsibilities around.
Braden
On Thu, Mar 13, 2014 at 2:10 PM, Marcel Kinard wrote:
> +1, I'm throwing my hat i
This is one of the several things I want to unify in CLI and Plugman, that
collectively argue for turning both the `cordova` and `plugman` packages
into thin wrappers around a common cordova-lib dependency.
I'm also prototyping some related crazy ideas, but it will be some weeks
before I have a ch
That's the plan. It's at 7pm ET, 4pm PT, which is midnight UTC.
Braden
On Tue, Mar 4, 2014 at 3:49 PM, Wargo, John wrote:
> Right?
>
>
That seems like a failing of those GUIs. When you git rebase -i from the
command line, it opens $EDITOR with the logs of all the commits that are
being squashed, but that's intended to give you context as you rewrite them
into a single, meaningful commit message that expresses the changes.
Braden
All the gory details of config files in CLI are here:
https://wiki.apache.org/cordova/config/cordova.xml
In short, that file is turned into a platform-specific config.xml during
the prepare step.
Your best approach to supporting this is probably to read config.xml in a
post-prepare hook. Then it
Responses inline.
On Thu, Feb 20, 2014 at 3:43 AM, Dominique Hazael-Massieux wrote:
> [resending, think my first attempt went before I finished subscribing]
>
> Hi all,
>
> Let me introduce myself quickly: I am part of the W3C staff, am
> responsible for supervising the mobile-related work in W3
I don't think there's been any work in this direction.
Braden
On Tue, Feb 18, 2014 at 10:47 AM, Lisa Seacat DeLuca wrote:
> Back in September our group chatted about making it possible to scaffold
> out a cordova plugin to ease the creation of new Cordova plugins for
> developers.
>
>
> http://
I think singleTop is "not recommended" for typical Android apps, that want
to go opening different activities using various Intents from
notifications. For something like Cordova, avoiding that restart is ideal.
Braden
On Fri, Feb 14, 2014 at 2:08 PM, Michal Mocny wrote:
> TLDR; AndroidManifes
First, a brief point: We do *not* follow the widget spec, not anymore. We
were close, a long time ago, but we've added multiple Cordova-specific or
Phonegap-specific things and some slight tweaks to the meaning of some tags
and attributes. Since the widget spec is officially deprecated, I argue
tha
han Bond-Caron <
jbo...@gdesolutions.com> wrote:
> On Tue Feb 11 11:05 AM, Braden Shepherdson wrote:
> > The intention is that it allows plugins to specify that they require at
> least a certain
> > version of the native code for each platform. This would be for things
The intention is that it allows plugins to specify that they require at
least a certain version of the native code for each platform. This would be
for things like added a new transport type to the bridge, as when we added
binary data transmission on iOS and Android a year or so ago. Any plugins
pu
I continue to feel that the right approach to platform updates is mostly to
keep making platforms/ a build artifact, and largely plugins/ too.
I feel that the right thing for an app developer to do for updating
platforms would be to backup the entire project, empty out platforms/ and
plugins/, and
Once upon a time serve served up the top level www/, then changed to
> platform www/.. should we change it back?
>
> I'm with Jesse that devs should not need (but can if they want) to version
> control platforms/ or plugins/, and his workaround seems quite agreeable to
> me.
&g
For the record, the App Harness makes child apps use the cordova.js,
cordova_plugins.js, and plugins/* which are included with the App Harness,
not the ones that come with the child app. This is because it ensures
compatibility with the native code and the Javascript side, though it can
break the J
I think all the inside slots are full. People are stalking the mailing list
if you have a comment.
Braden
On Wed, Jan 29, 2014 at 12:40 PM, Jonathan Bond-Caron <
jbo...@gdesolutions.com> wrote:
> Video call full?
>
> Great to see some faces,
> Cheers,
> Jon
>
> > -Original Message-
> >
We're not On Air yet. Andrew will post the viewing link shortly.
Braden
On Wed, Jan 29, 2014 at 12:30 PM, Lisa Seacat DeLuca wrote:
> What's the URL for the non-live people. The listeners? I dont' want to
> take up a spot for larger groups but I'd like to listen in.
>
>
>
> *Lisa Seacat DeLuc
I use CoffeeScript all the time in my own hackery. In Cordova, though, big
-1 to alternative languages. Let's keep it straight Javascript.
Otherwise these changes sound solid. You have to understand that these
tools, like any project that's been around longer than a few weeks, has had
several part
Unfortunately there are no such documents. I think the best references for
how the CLI works overall are my brain, and Anis' brain. Someday we should
write down an overview.
At a glance, it sounds like your bug might be caused by having a newer
cordova-android cached than 3.0.3 is expecting, causi
I don't know how much credit we can really claim. My intern and I just
found zip libraries for Android and iOS and wrapped them in a Cordova
plugin. They are handy when you need them, though.
Braden
On Tue, Jan 14, 2014 at 8:59 PM, Andrew Grieve wrote:
> Woohoo!
>
> On Tue, Jan 14, 2014 at 7:3
There was discussion some time ago about adding platform tags to the
top-level app config.xml, which could contain config-file tags to do what
you want. Having a plugin inject default values would not be supported,
though. The best you could do in that model would be printing a message at
install t
772>
This section would be better simply as:
return p.then(...
- Braden Shepherdson
On Jan. 7, 2014, 9:41 p.m., Mark Koudritsky wrote:
>
> ---
> This is an automatically generated e-mail. To reply,
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16701/#review31316
---
Ship it!
Ship It!
- Braden Shepherdson
On Jan. 7, 2014, 9:41
a's long-term goals. I try to gave more
> > > explanation, so you guys could plan not only for people which create
> > > projects which are working on the specific version of Cordova, but also
> > for
> > > the guys which want to nurture their product together w
and not the web community user base.
>
>
> On Mon, Jan 6, 2014 at 11:11 AM, Braden Shepherdson >wrote:
>
> > The unfortunate part is that Eclipse and Xcode are also (more or less)
> the
> > build systems for iOS and Android. You can build from CLI, and even
> deploy
The unfortunate part is that Eclipse and Xcode are also (more or less) the
build systems for iOS and Android. You can build from CLI, and even deploy
from the CLI if the stars align and you have your ruby slippers on the
correct feet, but in practice most people are launching from IDEs. That
makes
I've wanted to add Cordova plugin dependencies to the app's top-level
config.xml for a long time, but it's never reached the top of my
priorities. I think with that support, we can avoid checking in ./plugins/
and ./platforms altogether for 99% of app developers. If it doesn't solve
anyone's use ca
I'd be willing to write a Git 101, if there were interest there. We're all
familiar with the basics now, but some of the more extended features
(bisecting, stashes and rebases come to mind) might be of interest.
Braden
On Thu, Dec 12, 2013 at 3:00 PM, Brian LeRoux wrote:
> I've had some time t
I think this has been much discussed, but I'm not aware of it actually
being implemented.
Braden
On Tue, Dec 10, 2013 at 11:14 AM, Ian Clelland wrote:
> Do we have a way to specify, in plugin.xml, that a plugin depends on a
> given (minimum) version of another plugin?
>
> I was sure that we did
Make sure these platforms get added to cordova platform ls, with
appropriate logic for where Ubuntu can be built.
Braden
On Thu, Dec 5, 2013 at 6:02 PM, Andrew Grieve wrote:
> On Thu, Dec 5, 2013 at 8:53 PM, Steven Gill
> wrote:
>
> > Just wanted to give a update
> >
> > Support for both of t
d to use hooks to enforce ./platforms as a
> build
> > > > > artefact. Any progress towards the great goal of being able to
> safely
> > > > > .gitignore the platforms make me feel warm and fuzzy. ;)
> > > > >
> > > > >
> > > >
.
> > > >
> > > > But I hope we can agree that it should also be possible to override
> the
> > > > default without requiring hacks. iOS already supports this, so its a
> > > > matter of feature parity.
> > > >
> > > &
There are two different files here: one is defaults.xml, which the CLI
takes as the basis for its platform config.xml. The other is the config.xml
that you get after running bin/create. In the CLI world, that second file
is immediately overwritten by one created from defaults.xml, the top-level
app
My sufficient condition for merging this change is "it doesn't break
anything that already works", which includes our XML parsing, on any
desktop OS or mobile platform, or the CLI tools, choking on those BOMs.
Can you try it out on Linux or Mac to see what happens to the CLI tools? If
not, I guess
Our "review process" "works" by sending mail to this list, and then pinging
it after a few days go by with no action, and then pinging it again if we
still don't get to it. It's two parts diffusion of responsibility/hoping
someone else will get it, and one part the fact there's no list of
outstandi
889/#comment56830>
This is duplicating the logic in the lazy loader for checking for custom
configs and so on.
The correct flow is:
lazy_load.based_on_config(project_root, 'android').then(function(lib_path) {
// shell out to lib_path/bin/check_reqs
});
Revert them out if you like, that's the right flow for broken commits.
There's no need for a lecture on not checking in broken code - it wasn't
broken on our machines!
Braden
On Wed, Nov 27, 2013 at 1:36 PM, Steven Gill wrote:
> I see it is easy to fix by changing npm test to not run e2e test
on't come up after the cordova 3.3 release version bump.. so maybe its
> > low
> > > priority.
> > >
> > > In the mean time, now that we've shipped 3.2, shall we bump the version
> > on
> > > master?
> > >
> > >
> &g
#x27; or that complexity is
> > minimized by combining. Anyhow: not a discussion I think is even worth us
> > having AGAIN. =/
> >
> >
> > On Mon, Nov 25, 2013 at 10:32 AM, Braden Shepherdson <
> bra...@chromium.org
> > >wrote:
> >
> > > Hang
5/> last week and a test
> for it will be much better and easier in the e2e tests (got it ready
> locally). So I'm starting to depend on the e2e tests.
>
>
> On Thu, Nov 14, 2013 at 2:02 PM, Jonathan Bond-Caron <
> jbo...@gdesolutions.com> wrote:
>
>> On Thu
Hang on a second:
The release you send to the plugman registry doesn't care about git. You
point it at a (sub)directory and it uploads the plugin. The version is set
by the plugin.xml of that plugin.
If we want tags for when those plugins were pushed to npm, what's wrong
with tags like "whateverp
Looks good to me except for the change logs. They're too spammy. I think it
would be better to remove banal things like bumping the version and fixing
the tests, leaving only relevant changes. Also there's at least one pair of
making a change and reverting it, that should probably be dropped.
Brad
since these are
custom, bundled frameworks, there will never be any overlap. If so, then it's
fine.
- Braden Shepherdson
On Nov. 21, 2013, 3:26 a.m., Anis Kadri wrote:
>
> ---
> This is an automatically generated e-mail. To re
Whoops, I also meant to say, those LGTM, especially the first one. Much
more detailed docs for CLI are very welcome.
Braden
On Wed, Nov 20, 2013 at 1:20 PM, Braden Shepherdson wrote:
> Reviewboard was giving Mark problems last week, too. Pull requests are
> more convenient with the exc
Reviewboard was giving Mark problems last week, too. Pull requests are more
convenient with the exception that they send emails on every comment,
rather than buffering them until you submit the review. One of the Github's
oldest outstanding requests, etc. etc.
Braden
On Wed, Nov 20, 2013 at 12:2
al Mocny wrote:
> On Fri, Nov 15, 2013 at 4:25 PM, Jonathan Bond-Caron <
> jbo...@gdesolutions.com> wrote:
>
> > On Fri Nov 15 11:29 AM, Braden Shepherdson wrote:
> > > I propose three things:
> > > 1. Punt all discussion of overhauling configuration files to
ap but the class only
> > gets instantiated if "onload" is defined or if getPlugin() is
> > called when JS is called but exec not called for JS-only plugins
> > right?
> >
> Sorry, should have just tried it out before speaking up. I thought adding a
> null
:51, Andrew wrote:
>
> > ?
> >
> >
> > On Thu, Nov 14, 2013 at 11:44 AM, Braden Shepherdson <
> bra...@chromium.org (mailto:bra...@chromium.org)>wrote:
> >
> > > I think the "AND" logic was chosen because you can specify > > name
There's a bit of a BC issue here because cordova.js needs to know what file
to inject a
or writes this file directly in the
normal flow of things.
Braden
On Thu, Nov 14, 2013 at 3:29 PM, Braden Shepherdson wrote:
> There's a bit of a BC issue here because cordova.js needs to know what
> file to inject a
is is
written down anywhere right now, just in my and Anis's heads.
Braden
On Thu, Nov 14, 2013 at 2:41 PM, Brian LeRoux wrote:
> http://www.youtube.com/watch?v=a1N2k0-F1pU
>
>
> On Thu, Nov 14, 2013 at 9:11 AM, Braden Shepherdson >wrote:
>
> > We have reason n
---
> > From: Jesse [mailto:purplecabb...@gmail.com]
> > Sent: Wednesday, November 6, 2013 11:18 PM
> > To: dev@cordova.apache.org
> > Subject: Re: Platforms which are in subdirectory in repositories can't be
> > added by cli since 3.1.0-0.2.0
> >
&g
Brian, I think you're a bit confused about which information is in what
files. I can break that down here if people would find it valuable.
That timing works for me, Anis. I'll see you, and any other interested
parties, there and then. If you're not Anis, add +Braden Shepherdson ah
nt-25952856
>
> On Thu, Nov 14, 2013 at 10:53 AM, Braden Shepherdson
> wrote:
> > I apologize for getting somewhat short in my previous email.
> >
> > Let me explain my comment on needing "more, and more hacky, code".
> Because
> > of how Plugman parse
Adding makes sense to me, and we may as well throw in at the
same time.
I think the default logic should still be AND.
Braden
On Thu, Nov 14, 2013 at 1:51 PM, Andrew Grieve wrote:
> ?
>
>
> On Thu, Nov 14, 2013 at 11:44 AM, Braden Shepherdson >wrote:
>
> > I t
nto userland, these tags are relevant to plugin
> > developers" ... so would this particular information belong to
> > plugin.xml
> >
> > Also, Joe had a good question earlier. Despite all this problem solving I
> > have no idea what the actual problem is we
ckage params. That being said, I'm not sure what the
> > point would even be, since JS-only plugins aren't really plugins at
> > all and are just Javascript libraries. Are there current examples of
> > this in Cordova currently?
> >
> > >
> > > O
We have reason not to move ./plugins/*.json into .cordova/config.json is
that the latter file doesn't exist unless you're using CLI, whereas Plugman
needs and maintains the ./plugins/*.json files.
Braden
On Thu, Nov 14, 2013 at 9:19 AM, Michal Mocny wrote:
> ;) http://xkcd.com/927/
>
> Some mo
I think the "AND" logic was chosen because you can specify or similar, in order to require
sufficiently new versions of the platforms.
I agree that only makes sense for platform engines, and makes worklight vs.
phonegap vs. cordova engines broken. I don't know how we want to handle
that.
Braden
Generally speaking, adding new dependencies is fine, so long as they aren't
too extensive. A markdown parser and friendlier JSON parsing are probably
fine to add, since they're not going to be adding five megs and a dozen
transitive deps.
Those changes look fine to me. Do we have a use-case for ex
> 2. plugin's js -> change all service names to ID in cordova.exec
> > >
> > > For user upgrades, they would remove the old plugin, then add the new
> > one -
> > > so it's relatively painless I think.
> > >
> > >
> > > On Wed
n.
>
> And apparently adobe sf just had a coffee break...
> --
> Gorkem
>
>
> On Wed, Nov 13, 2013 at 4:27 PM, Braden Shepherdson >wrote:
>
> > I'm open to changing the names to something else, since I realize there
> > used to be a tag and tags inside, b
d a few minutes in
> those
> > > platforms would probably be a good thing anyway.
> > >
> > > I too am also not sure why the existing feature tag in config.xml is
> not
> > > enough.
> > >
> > >
> > >
> > > @purplecabba
http://www.w3.org/TR/widgets/#feature
>
> On Wed, Nov 13, 2013 at 12:23 PM, Braden Shepherdson
> wrote:
> > The tags list only those plugins which are relevant to the
> > bridge. Also they map from exec bridge name to native code class name,
> and
> > have no information
scanner plugin from the registry. As an
> alternate, tag can be used and id and version info can be
> injected as additional tags by plugman.
>
>
> [1]
> value="com.phonegap.plugins.barcodescanner.BarcodeScanner"/>
>
> --
> Gorke
ing feature tag in config.xml is not
> enough.
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Wed, Nov 13, 2013 at 11:38 AM, Gorkem Ercan >wrote:
>
> > Hey Braden,
> > Why is not the current tags sufficient for this?
> > --
> > Gorkem
>
Hey folks,
We've been kicking around the idea of getting at which plugins/versions are
installed, at runtime. In order to make that happen, I've taken the first
step of having plugman prepare insert a tag into config.xml for each
plugin. It will look like this:
NB that Plugman is injecti
I think people are not aware that the semantics of the serve command
changed a while ago.
The correct steps now are:
- run "cordova serve", with no platform named.
- go to http://localhost:8000/android or some other platform you have
installed
- it works, you can fetch the various assets. Cordova
Following up here with the note that there's a public branch called
e2e-tests with working tests for create and platform commands. These tests
are touching the real filesystem using only slightly hacked-up fixtures.
A couple of things we learned: the res/ directory in the helloworld
template is 3M
Actually, it's only in some provinces, like BC. Notable exceptions include
Ontario, so the Waterloo-based Google team is still around today.
Braden
On Mon, Nov 11, 2013 at 11:45 AM, purplecabbage wrote:
> Today is a statutory holiday in Canada; Just in case anyone was expecting
> and not receiv
common with other Node.js based
> projects
> > and the distinction between unit and integration tests is somewhat
> blurred
> > here.
> >
> > Anyway, as Braden said, we'll see what parts of the end-to-end tests will
> > be slow and work on speeding some of
There is one big, crippling bug in the released plugman: If you add a
capability with Xcode 5, you can no longer plugman.prepare, and therefore
not rebuild your app.
I don't think releasing them separately is a good idea. I'm prepared to
wait until 3.2 to release both, but only if that's less than
A few users requested on a Plugman bug (the Xcode 5 capabilities one) that
we do a tools release soon, in order to get that fix out.
I'm in favour of it. Any objections to my doing a tools release this
afternoon (say T-3 hours)?
Braden
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/15328/#review28455
---
Ship it!
Ship It!
- Braden Shepherdson
On Nov. 7, 2013, 9:59
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/15253/#review28451
---
Ship it!
Ship It!
- Braden Shepherdson
On Nov. 6, 2013, 1:11
ows.
>
> On Thu, Nov 7, 2013 at 10:31 AM, Braden Shepherdson
> wrote:
> > Alright, Mark and I have discussed this further, and we will be beginning
> > the effort with some end-to-end tests that will supplement the existing
> > tests.
> >
> > To some extent t
gt; >> Likely we want to ship those end-to-end test scripts so users can test
> >> changes locally, but I think the tests are are inside CLI now are meant
> to
> >> be unit tests, which yes, have very limited usefulness in isolation, but
> >> perhaps shou
The CLI tests are bad. I propose making them better.
The tests are bad for two reasons:
1. They're fragile because the tests depend on exactly the right functions
being called, sometimes in the right order.
2. They don't test what we really want, which is that projects get created
and all the file
I think some people are confused about this number and backward
compatibility.
There are *two* version constraints on Android. The one we're discussing
here is which API we're compiling against, which should generally be set at
the latest stable version (+1 to 3.2 targeting API 18 (Android 4.3)).
uchit.fr
> 06 28 60 72 34
> http://touchit.fr
>
> -Original Message-
> From: bra...@google.com [mailto:bra...@google.com] On Behalf Of Braden
> Shepherdson
> Sent: mercredi 6 novembre 2013 19:22
> To: dev@cordova.apache.org
> Subject: Re: Platforms which are i
Commented on the PR.
On Wed, Nov 6, 2013 at 1:20 PM, Maxime LUCE wrote:
> Hello,
>
> I found that platforms which are in a subdirectory of their repository
> can't be added by cli.
> I found that in the commit d75c0585c88ee9283db400f0c946027bd9d6e1ea in
> cordova-cli repository, someone removed
I've added more comments to CB-4609 about this. tl;dr use a post-prepare
hook for this kind of custom behavior.
Braden
On Wed, Nov 6, 2013 at 8:47 AM, Jonathan Bond-Caron wrote:
> On Wed Nov 6 01:54 AM, Darryl Pogue wrote:
> > On 5 November 2013 13:37, Braden Shepherd
Why is any development here happening outside of Cordova? Most apps are
going to depend on Cordova APIs too deeply to get all that far with the
early steps in your outline.
Braden
On Tue, Nov 5, 2013 at 4:35 PM, Jonathan Bond-Caron wrote:
> On Mon Nov 4 11:00 AM, Josh Soref wrote:
> > https://
I don't know how this value got updated in the past, it should presumably
be set to target the latest version of Android.
+1 for bumping it to 19.
Braden
On Tue, Nov 5, 2013 at 4:19 PM, Gorkem Ercan wrote:
> Hello,
> Does anyone recall the reason for CLI to having "android-17" as a hard
> tar
This sounds like a bug in BB10. The aliasing is the intended behavior and
supposed to work - both sides of cordova.exec should be using the name from
the tag, not the plugin ID.
Braden
On Mon, Nov 4, 2013 at 12:33 PM, Don Coleman wrote:
> I think you're right about plugman not guaranteeing un
> ...I'm imagining a split file system where Cordova is perhaps FAT and the
> target is anything else...
This isn't a concern. That potential problem is not unique to Cordova, and
so when Unixy systems view or copy from permission-less filesystems like
FAT, they generally set 777, or at least 7xx
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/15046/#review27917
---
Ship it!
Ship It!
- Braden Shepherdson
On Oct. 30, 2013, 4:12
Wed, Oct 23, 2013 at 2:39 PM, Axel Nennker
> wrote:
>
> > Yes, a copy is simpler but I think that copying only the needed files
> > specified in plugin.xml makes a lot of sense.
> > Am 23.10.2013 16:42 schrieb "Braden Shepherdson" :
> >
> > > The
ent to keep examples in the same repo as the code.
>
>
> On Wed, Oct 23, 2013 at 10:42 AM, Braden Shepherdson >wrote:
>
> > The common places to fetch the plugin are over the network, from the
> plugin
> > registry or from git. Therefore the tools are expecting to downl
As long as we are still tracking mostly by the version numbers on JIRA and
so on, I'm okay with silly marketing names. Too bad these suggested schemes
don't support "Fancy Pants".
I'm perfectly happy with nonsensical names; I think the AngularJS
releases[1] are hilarious. (radioactive-gargle, bewi
I thought we were shelling out that command, not trying to load the file.
Then Windows would locate the version.bat file and run it, while Unixy
platforms would see the version file with +x, and run it.
Are we no longer going through the shell? (This should be using
child_process.exec, not .spawn,
The common places to fetch the plugin are over the network, from the plugin
registry or from git. Therefore the tools are expecting to download exactly
the files that are needed by the plugin, plus or minus a README or
whatever. They expect local plugins to be self-contained, in a directory by
them
1 - 100 of 362 matches
Mail list logo
