Re: cordova-plugins repo release
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 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 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 look for a > > > "Updated version to x.x.x" commit. > > > > > > Do we need tags at all? > > > > > > > > > On Mon, Nov 25, 2013 at 6:32 PM, Brian LeRoux wrote: > > > > > > > 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: > > > > > > 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 pushed over a few hundred repositories :). > > > > > > > > > > > - > > > > > This transmission (including any attachments) may contain > > confidential > > > > > information, privileged material (including material protected by > the > > > > > solicitor-client or other applicable privileges), or constitute > > > > non-public > > > > > information. Any use of this information by anyone other than the > > > > intended > > > > > recipient is prohibited. If you have received this transmission in > > > error, > > > > > please immediately reply to the sender and delete this information > > from > > > > > your system. Use, dissemination, distribution, or reproduction of > > this > > > > > transmission by unintended recipients is not authorized and may be > > > > unlawful. > > > > > > > > > > > > > > > > > > > >
Re: cordova-plugins repo release
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 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 look for a > > "Updated version to x.x.x" commit. > > > > Do we need tags at all? > > > > > > On Mon, Nov 25, 2013 at 6:32 PM, Brian LeRoux wrote: > > > > > 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: > > > > > 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 pushed over a few hundred repositories :). > > > > > > > > - > > > > This transmission (including any attachments) may contain > confidential > > > > information, privileged material (including material protected by the > > > > solicitor-client or other applicable privileges), or constitute > > > non-public > > > > information. Any use of this information by anyone other than the > > > intended > > > > recipient is prohibited. If you have received this transmission in > > error, > > > > please immediately reply to the sender and delete this information > from > > > > your system. Use, dissemination, distribution, or reproduction of > this > > > > transmission by unintended recipients is not authorized and may be > > > unlawful. > > > > > > > > > > > > > >
Re: cordova-plugins repo release
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 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 look for a > "Updated version to x.x.x" commit. > > Do we need tags at all? > > > On Mon, Nov 25, 2013 at 6:32 PM, Brian LeRoux wrote: > > > 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: > > > > 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 pushed over a few hundred repositories :). > > > > > > - > > > This transmission (including any attachments) may contain confidential > > > information, privileged material (including material protected by the > > > solicitor-client or other applicable privileges), or constitute > > non-public > > > information. Any use of this information by anyone other than the > > intended > > > recipient is prohibited. If you have received this transmission in > error, > > > please immediately reply to the sender and delete this information from > > > your system. Use, dissemination, distribution, or reproduction of this > > > transmission by unintended recipients is not authorized and may be > > unlawful. > > > > > > > > >
Re: cordova-plugins repo release
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 look for a "Updated version to x.x.x" commit. Do we need tags at all? On Mon, Nov 25, 2013 at 6:32 PM, Brian LeRoux wrote: > 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: > > > 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 pushed over a few hundred repositories :). > > > > - > > This transmission (including any attachments) may contain confidential > > information, privileged material (including material protected by the > > solicitor-client or other applicable privileges), or constitute > non-public > > information. Any use of this information by anyone other than the > intended > > recipient is prohibited. If you have received this transmission in error, > > please immediately reply to the sender and delete this information from > > your system. Use, dissemination, distribution, or reproduction of this > > transmission by unintended recipients is not authorized and may be > unlawful. > > > > >
Re: cordova-plugins repo release
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: > > 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 pushed over a few hundred repositories :). > > - > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. > >
Re: cordova-plugins repo release
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 pushed over a few hundred repositories :). - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: cordova-plugins repo release
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 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 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 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 > > > to having real repos. > > > > > > Braden > > > > > > > > > On Mon, Nov 25, 2013 at 2:44 PM, Michal Mocny > > wrote: > > > > > >> 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/incubation period so you don't have to file a ticket with > > INFRA > > >> before you even get started. > > >> > > >> Seems the two published plugins are keyboard and statusbar, so we > should > > >> get INFRA tickets to make repos for those? > > >> > > >> -Michal > > >> > > >> > > >> On Mon, Nov 25, 2013 at 10:47 AM, Brian LeRoux wrote: > > >> > > >> > 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 < > > >> bra...@chromium.org > > >> > >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 "whateverplugin-1.0.0"? It's a little cluttered to > > see > > >> all > > >> > > the tags for all the plugins, but you can still see all the > releases > > >> of a > > >> > > given plugin. They're in this repo precisely because they're small > > or > > >> > > experimental and not ready for their own repos yet. > > >> > > > > >> > > -10 to one repo per plugin; we have way too many repos already, > and > > >> this > > >> > > cordova-plugins repo is intended to be the catchall place for > small > > and > > >> > > experimental plugins. > > >> > > > > >> > > Braden > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > On Mon, Nov 25, 2013 at 11:05 AM, Michal Mocny < > mmo...@chromium.org > > > > > >> > > wrote: > > >> > > > > >> > > > 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 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 changed. > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > @purplecabbage > > >> > > > > risingj.com > > >> > > > > > > >> > > > > > > >> > > > > On Fri, Nov 22, 2013 at 6:36 PM, Michal Mocny < > > mmo...@chromium.org > > >> > > > >> > > > wrote: > > >> > > > > > > >> > > > > > 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 > > >
Re: cordova-plugins repo release
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 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 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 > > to having real repos. > > > > Braden > > > > > > On Mon, Nov 25, 2013 at 2:44 PM, Michal Mocny > wrote: > > > >> 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/incubation period so you don't have to file a ticket with > INFRA > >> before you even get started. > >> > >> Seems the two published plugins are keyboard and statusbar, so we should > >> get INFRA tickets to make repos for those? > >> > >> -Michal > >> > >> > >> On Mon, Nov 25, 2013 at 10:47 AM, Brian LeRoux wrote: > >> > >> > 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 < > >> bra...@chromium.org > >> > >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 "whateverplugin-1.0.0"? It's a little cluttered to > see > >> all > >> > > the tags for all the plugins, but you can still see all the releases > >> of a > >> > > given plugin. They're in this repo precisely because they're small > or > >> > > experimental and not ready for their own repos yet. > >> > > > >> > > -10 to one repo per plugin; we have way too many repos already, and > >> this > >> > > cordova-plugins repo is intended to be the catchall place for small > and > >> > > experimental plugins. > >> > > > >> > > Braden > >> > > > >> > > > >> > > > >> > > > >> > > On Mon, Nov 25, 2013 at 11:05 AM, Michal Mocny > > >> > > wrote: > >> > > > >> > > > 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 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 changed. > >> > > > > > >> > > > > > >> > > > > > >> > > > > @purplecabbage > >> > > > > risingj.com > >> > > > > > >> > > > > > >> > > > > On Fri, Nov 22, 2013 at 6:36 PM, Michal Mocny < > mmo...@chromium.org > >> > > >> > > > wrote: > >> > > > > > >> > > > > > 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 > >> > > > > > plugins in cordova-plugins existed back then, so we just set > >> engine > >> > > > > > requirement to 3.1? > >> > > > > > > >> > > > > > -Michal > >> > > > > > > >> > > > > > > >> > > > > > On Fri, Nov 22, 2013 at 1:32 PM, Steven Gill < > >> > stevengil...@gmail.com > >> > > > > >> > > > > > wrote: > >> > > > > > > >> > > > > > > +1 on one plugin per repo. Would making releasing and > tagging > >> > much > >> > > > > > simpler. > >> > > > > > > >
Re: cordova-plugins repo release
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 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 > to having real repos. > > Braden > > > On Mon, Nov 25, 2013 at 2:44 PM, Michal Mocny wrote: > >> 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/incubation period so you don't have to file a ticket with INFRA >> before you even get started. >> >> Seems the two published plugins are keyboard and statusbar, so we should >> get INFRA tickets to make repos for those? >> >> -Michal >> >> >> On Mon, Nov 25, 2013 at 10:47 AM, Brian LeRoux wrote: >> >> > 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 < >> bra...@chromium.org >> > >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 "whateverplugin-1.0.0"? It's a little cluttered to see >> all >> > > the tags for all the plugins, but you can still see all the releases >> of a >> > > given plugin. They're in this repo precisely because they're small or >> > > experimental and not ready for their own repos yet. >> > > >> > > -10 to one repo per plugin; we have way too many repos already, and >> this >> > > cordova-plugins repo is intended to be the catchall place for small and >> > > experimental plugins. >> > > >> > > Braden >> > > >> > > >> > > >> > > >> > > On Mon, Nov 25, 2013 at 11:05 AM, Michal Mocny >> > > wrote: >> > > >> > > > 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 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 changed. >> > > > > >> > > > > >> > > > > >> > > > > @purplecabbage >> > > > > risingj.com >> > > > > >> > > > > >> > > > > On Fri, Nov 22, 2013 at 6:36 PM, Michal Mocny > > >> > > > wrote: >> > > > > >> > > > > > 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 >> > > > > > plugins in cordova-plugins existed back then, so we just set >> engine >> > > > > > requirement to 3.1? >> > > > > > >> > > > > > -Michal >> > > > > > >> > > > > > >> > > > > > On Fri, Nov 22, 2013 at 1:32 PM, Steven Gill < >> > stevengil...@gmail.com >> > > > >> > > > > > wrote: >> > > > > > >> > > > > > > +1 on one plugin per repo. Would making releasing and tagging >> > much >> > > > > > simpler. >> > > > > > > >> > > > > > > >> > > > > > > On Fri, Nov 22, 2013 at 1:29 PM, Carlos Santana < >> > > > csantan...@gmail.com >> > > > > > > >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 strongly encourage one >> plugin >> > > per >> > > > > repo >> > > > > > > > containing its own version and source control. >> > > > > > > > >> > > > > > > > >> > > > > > > > On Friday, November 22, 2013, Shazron wrote: >> > >
Re: cordova-plugins repo release
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 to having real repos. Braden On Mon, Nov 25, 2013 at 2:44 PM, Michal Mocny wrote: > 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/incubation period so you don't have to file a ticket with INFRA > before you even get started. > > Seems the two published plugins are keyboard and statusbar, so we should > get INFRA tickets to make repos for those? > > -Michal > > > On Mon, Nov 25, 2013 at 10:47 AM, Brian LeRoux wrote: > > > 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 < > bra...@chromium.org > > >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 "whateverplugin-1.0.0"? It's a little cluttered to see > all > > > the tags for all the plugins, but you can still see all the releases > of a > > > given plugin. They're in this repo precisely because they're small or > > > experimental and not ready for their own repos yet. > > > > > > -10 to one repo per plugin; we have way too many repos already, and > this > > > cordova-plugins repo is intended to be the catchall place for small and > > > experimental plugins. > > > > > > Braden > > > > > > > > > > > > > > > On Mon, Nov 25, 2013 at 11:05 AM, Michal Mocny > > > wrote: > > > > > > > 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 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 changed. > > > > > > > > > > > > > > > > > > > > @purplecabbage > > > > > risingj.com > > > > > > > > > > > > > > > On Fri, Nov 22, 2013 at 6:36 PM, Michal Mocny > > > > > wrote: > > > > > > > > > > > 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 > > > > > > plugins in cordova-plugins existed back then, so we just set > engine > > > > > > requirement to 3.1? > > > > > > > > > > > > -Michal > > > > > > > > > > > > > > > > > > On Fri, Nov 22, 2013 at 1:32 PM, Steven Gill < > > stevengil...@gmail.com > > > > > > > > > > wrote: > > > > > > > > > > > > > +1 on one plugin per repo. Would making releasing and tagging > > much > > > > > > simpler. > > > > > > > > > > > > > > > > > > > > > On Fri, Nov 22, 2013 at 1:29 PM, Carlos Santana < > > > > csantan...@gmail.com > > > > > > > >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 strongly encourage one > plugin > > > per > > > > > repo > > > > > > > > containing its own version and source control. > > > > > > > > > > > > > > > > > > > > > > > > On Friday, November 22, 2013, Shazron wrote: > > > > > > > > > > > > > > > > > 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 > >
Re: cordova-plugins repo release
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/incubation period so you don't have to file a ticket with INFRA before you even get started. Seems the two published plugins are keyboard and statusbar, so we should get INFRA tickets to make repos for those? -Michal On Mon, Nov 25, 2013 at 10:47 AM, Brian LeRoux wrote: > 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 "whateverplugin-1.0.0"? It's a little cluttered to see all > > the tags for all the plugins, but you can still see all the releases of a > > given plugin. They're in this repo precisely because they're small or > > experimental and not ready for their own repos yet. > > > > -10 to one repo per plugin; we have way too many repos already, and this > > cordova-plugins repo is intended to be the catchall place for small and > > experimental plugins. > > > > Braden > > > > > > > > > > On Mon, Nov 25, 2013 at 11:05 AM, Michal Mocny > > wrote: > > > > > 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 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 changed. > > > > > > > > > > > > > > > > @purplecabbage > > > > risingj.com > > > > > > > > > > > > On Fri, Nov 22, 2013 at 6:36 PM, Michal Mocny > > > wrote: > > > > > > > > > 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 > > > > > plugins in cordova-plugins existed back then, so we just set engine > > > > > requirement to 3.1? > > > > > > > > > > -Michal > > > > > > > > > > > > > > > On Fri, Nov 22, 2013 at 1:32 PM, Steven Gill < > stevengil...@gmail.com > > > > > > > > wrote: > > > > > > > > > > > +1 on one plugin per repo. Would making releasing and tagging > much > > > > > simpler. > > > > > > > > > > > > > > > > > > On Fri, Nov 22, 2013 at 1:29 PM, Carlos Santana < > > > csantan...@gmail.com > > > > > > >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 strongly encourage one plugin > > per > > > > repo > > > > > > > containing its own version and source control. > > > > > > > > > > > > > > > > > > > > > On Friday, November 22, 2013, Shazron wrote: > > > > > > > > > > > > > > > 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 > > > > > > > > problematic because we have multiple plugins in that one > repo. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Carlos Santana > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: cordova-plugins repo release
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 "whateverplugin-1.0.0"? It's a little cluttered to see all > the tags for all the plugins, but you can still see all the releases of a > given plugin. They're in this repo precisely because they're small or > experimental and not ready for their own repos yet. > > -10 to one repo per plugin; we have way too many repos already, and this > cordova-plugins repo is intended to be the catchall place for small and > experimental plugins. > > Braden > > > > > On Mon, Nov 25, 2013 at 11:05 AM, Michal Mocny > wrote: > > > 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 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 changed. > > > > > > > > > > > > @purplecabbage > > > risingj.com > > > > > > > > > On Fri, Nov 22, 2013 at 6:36 PM, Michal Mocny > > wrote: > > > > > > > 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 > > > > plugins in cordova-plugins existed back then, so we just set engine > > > > requirement to 3.1? > > > > > > > > -Michal > > > > > > > > > > > > On Fri, Nov 22, 2013 at 1:32 PM, Steven Gill > > > > > wrote: > > > > > > > > > +1 on one plugin per repo. Would making releasing and tagging much > > > > simpler. > > > > > > > > > > > > > > > On Fri, Nov 22, 2013 at 1:29 PM, Carlos Santana < > > csantan...@gmail.com > > > > > >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 strongly encourage one plugin > per > > > repo > > > > > > containing its own version and source control. > > > > > > > > > > > > > > > > > > On Friday, November 22, 2013, Shazron wrote: > > > > > > > > > > > > > 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 > > > > > > > problematic because we have multiple plugins in that one repo. > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Carlos Santana > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: cordova-plugins repo release
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 "whateverplugin-1.0.0"? It's a little cluttered to see all the tags for all the plugins, but you can still see all the releases of a given plugin. They're in this repo precisely because they're small or experimental and not ready for their own repos yet. -10 to one repo per plugin; we have way too many repos already, and this cordova-plugins repo is intended to be the catchall place for small and experimental plugins. Braden On Mon, Nov 25, 2013 at 11:05 AM, Michal Mocny wrote: > 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 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 changed. > > > > > > > > @purplecabbage > > risingj.com > > > > > > On Fri, Nov 22, 2013 at 6:36 PM, Michal Mocny > wrote: > > > > > 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 > > > plugins in cordova-plugins existed back then, so we just set engine > > > requirement to 3.1? > > > > > > -Michal > > > > > > > > > On Fri, Nov 22, 2013 at 1:32 PM, Steven Gill > > > wrote: > > > > > > > +1 on one plugin per repo. Would making releasing and tagging much > > > simpler. > > > > > > > > > > > > On Fri, Nov 22, 2013 at 1:29 PM, Carlos Santana < > csantan...@gmail.com > > > > >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 strongly encourage one plugin per > > repo > > > > > containing its own version and source control. > > > > > > > > > > > > > > > On Friday, November 22, 2013, Shazron wrote: > > > > > > > > > > > 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 > > > > > > problematic because we have multiple plugins in that one repo. > > > > > > > > > > > > > > > > > > > > > -- > > > > > Carlos Santana > > > > > > > > > > > > > > > > > > > >
Re: cordova-plugins repo release
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 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 changed. > > > > @purplecabbage > risingj.com > > > On Fri, Nov 22, 2013 at 6:36 PM, Michal Mocny wrote: > > > 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 > > plugins in cordova-plugins existed back then, so we just set engine > > requirement to 3.1? > > > > -Michal > > > > > > On Fri, Nov 22, 2013 at 1:32 PM, Steven Gill > > wrote: > > > > > +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 strongly encourage one plugin per > repo > > > > containing its own version and source control. > > > > > > > > > > > > On Friday, November 22, 2013, Shazron wrote: > > > > > > > > > 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 > > > > > problematic because we have multiple plugins in that one repo. > > > > > > > > > > > > > > > > > -- > > > > Carlos Santana > > > > > > > > > > > > > >
Re: cordova-plugins repo release
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 changed. @purplecabbage risingj.com On Fri, Nov 22, 2013 at 6:36 PM, Michal Mocny wrote: > 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 > plugins in cordova-plugins existed back then, so we just set engine > requirement to 3.1? > > -Michal > > > On Fri, Nov 22, 2013 at 1:32 PM, Steven Gill > wrote: > > > +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 strongly encourage one plugin per repo > > > containing its own version and source control. > > > > > > > > > On Friday, November 22, 2013, Shazron wrote: > > > > > > > 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 > > > > problematic because we have multiple plugins in that one repo. > > > > > > > > > > > > > -- > > > Carlos Santana > > > > > > > > >
Re: cordova-plugins repo release
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 plugins in cordova-plugins existed back then, so we just set engine requirement to 3.1? -Michal On Fri, Nov 22, 2013 at 1:32 PM, Steven Gill wrote: > +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 strongly encourage one plugin per repo > > containing its own version and source control. > > > > > > On Friday, November 22, 2013, Shazron wrote: > > > > > 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 > > > problematic because we have multiple plugins in that one repo. > > > > > > > > > -- > > Carlos Santana > > > > >
Re: cordova-plugins repo release
+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 strongly encourage one plugin per repo > containing its own version and source control. > > > On Friday, November 22, 2013, Shazron wrote: > > > 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 > > problematic because we have multiple plugins in that one repo. > > > > > -- > Carlos Santana > >
Re: cordova-plugins repo release
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-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 > problematic because we have multiple plugins in that one repo. > -- Carlos Santana
cordova-plugins repo release
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 problematic because we have multiple plugins in that one repo.
