Yeah I have been saying to do them independent of the plugin releases I do.
The authors have been doing that so far.
On Thu, Nov 28, 2013 at 12:01 PM, Brian LeRoux wrote:
> ya I think/thought so too
>
>
> On Wed, Nov 27, 2013 at 8:41 PM, Michal Mocny wrote:
>
> > I think the conclusion was tha
ya I think/thought so too
On Wed, Nov 27, 2013 at 8:41 PM, Michal Mocny wrote:
> I think the conclusion was that cordova-plugins are just *not* included in
> plugin releases.
>
>
> On Wed, Nov 27, 2013 at 11:32 PM, Andrew Grieve >wrote:
>
> > Back to the original question - we should specify h
I think the conclusion was that cordova-plugins are just *not* included in
plugin releases.
On Wed, Nov 27, 2013 at 11:32 PM, Andrew Grieve wrote:
> Back to the original question - we should specify how cordova-plugins
> should be included in plugin releases.
>
> Really, the thing we need is to
Back to the original question - we should specify how cordova-plugins
should be included in plugin releases.
Really, the thing we need is to be able to know if there are any unreleased
commits and to update releasenotes.md for each plugin.
I think it'd be enough to run "git log -- plugin-dir" and
the problem wasn't isolated to the repo (there were many problems) but
suffice to say lack of shared issue tracking was a key point of failure and
inability to discreetly version changesets created more suffering than good
On Mon, Nov 25, 2013 at 3:20 PM, Josh Soref wrote:
> Lindsey Simon wrote
Lindsey Simon wrote:
> It seems like a shared repo is just a recipe for the troubles of the last
> shared repo.
For those of us who didn't live through the last shared repo, is there a
document describing what happened?
There's a great writeup from some Github using group who accidentally force
It seems like a shared repo is just a recipe for the troubles of the last
shared repo.
On Mon, Nov 25, 2013 at 1:17 PM, Jesse wrote:
> All of this is fine.
>
> I also see no reason why you cannot hack in your own repo, just ensure you
> start with the right license. Nothing says that the apach
All of this is fine.
I also see no reason why you cannot hack in your own repo, just ensure you
start with the right license. Nothing says that the apache git has to be
the origin of code.
@purplecabbage
risingj.com
On Mon, Nov 25, 2013 at 1:01 PM, Anis KADRI wrote:
> It sounds like we all
It sounds like we all agree. Start hacking on cordova-plugins and
if/when it's mature move it to its own repository. Publishig from
cordova-plugins should not be an issue.
On Mon, Nov 25, 2013 at 11:52 AM, Braden Shepherdson
wrote:
> I'm not sure if I was clear: I am content with the current repo
I'm not sure if I was clear: I am content with the current repo setup and
argue for keeping it as it is. The main core plugins are in their own repos
and I support that. On the other hand I support having the cordova-plugins
repo as an incubator for experimental projects that either die or graduate
Okay -- while I do agree with Braden -- in the interests of not debating
again, I'll concede to not publishing core plugins from a shared repo (if
for no other reason than for consistency with the other core plugins). But
I think its still worth having a cordova-plugins repo for early
experiments/
Super disagree about putting src into a single big repo. I get why we do
that. I do not buy that we 'have too many repos' 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 wrote:
>
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
Would that only be true if you shared readable tag names between plugins?
If we used tags unique to each plugin, perhaps by prefixing tags with the
target plugins' name, then plugin releases would be isolated, right?
-Michal
On Fri, Nov 22, 2013 at 8:02 PM, Jesse wrote:
> The issue that if us
The issue that if use a tag to signify the new version, then the tag is
applied to all plugins in the repo. This is probably not a big deal for
minor bumps, but when a plugin needs a major bump, they all will. So you
will/could have a plugin with a major version bump even though the code has
not ch
I don't understand, whats the problem? I thought you publish plugins by
git-repo & subdir & hash -- so multiple plugins makes no difference.
The master & dev branch deal was to do with cordova-3.0 users that did not
support plugin repo install from !master branch, right? But none of these
plugin
+1 on one plugin per repo. Would making releasing and tagging much simpler.
On Fri, Nov 22, 2013 at 1:29 PM, Carlos Santana wrote:
> Yep that's the problem with having independent plugins in a single repo,
> and just using directories to separate them.
>
> If I would have a choice I would strong
Yep that's the problem with having independent plugins in a single repo,
and just using directories to separate them.
If I would have a choice I would strongly encourage one plugin per repo
containing its own version and source control.
On Friday, November 22, 2013, Shazron wrote:
> The cordova
The cordova-plugins repo has plugins as well, but are outside of the
purview of the planned weekly core plugins release - I plan to upload
independently.
The repo does not have the concept of "dev" and "master" plugins as well
like the core plugins. It was suggested we have tags, but this is
probl
19 matches
Mail list logo
