Re: Plugin / Platform mismatch problems
I would like to resolve this issue On 8/1/13, Shazron wrote: > Filed: https://issues.apache.org/jira/browse/CB-4477 > > > On Wed, Jul 31, 2013 at 10:48 AM, Anis KADRI wrote: > >> I feel like we shouldn't. More source of errors than anything I think. >> Also human readable names are useless when presented in search results >> because one can't install using a human readable name. >> >> Shaz, I think we do need to add a doc issue. >> >> On Wed, Jul 31, 2013 at 10:30 AM, Andrew Grieve >> wrote: >> > I don't feel strongly one way or the other about prefixing. >> > >> > >> > On Tue, Jul 30, 2013 at 6:49 PM, Shazron wrote: >> > >> >> Do we need to add a doc issue for updating this in 3.1: >> >> 1. >> >> >> >> >> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_plugman.md.html#Using%20Plugman%20to%20Manage%20Plugins >> >> 2. >> >> >> >> >> http://cordova.apache.org/docs/en/3.0.0/guide_cli_index.md.html#The%20Command-line%20Interface >> >> >> >> (the docs will still work of course using the existing method) >> >> >> >> >> >> On Tue, Jul 30, 2013 at 3:33 PM, Anis KADRI >> wrote: >> >> >> >> > In the meantimeI renamed all plugins to package names in the >> >> > cordova registry. I've also updated plugman >> >> > >> >> > So anyone should be able to `cordova plugin add >> >> > org.apache.cordova.core.device` or `plugman install --platform >> >> > platform --plugin org.apache.cordova.core.device --project >> >> > /path/to/project` and it should just work. >> >> > >> >> > prefixing is not there yet. Do we really want it ? >> >> > >> >> > -a >> >> > >> >> > On Tue, Jul 30, 2013 at 9:58 AM, Brian LeRoux wrote: >> >> > > Oh, yes, it could also be made to install from the npm registry. >> >> > > It >> >> > > does neither of those things yet. >> >> > > >> >> > > On Tue, Jul 30, 2013 at 9:43 AM, Andrew Grieve < >> agri...@chromium.org> >> >> > wrote: >> >> > >> A federated system just means that anyone can host a directory of >> >> > plugins, >> >> > >> yes? Anis was saying that plugman could be easily made to point >> >> > >> at >> any >> >> > >> couchdb instance. Is that not federated? >> >> > >> >> >> > >> >> >> > >> On Mon, Jul 29, 2013 at 11:38 PM, Brian LeRoux >> >> > >> wrote: >> >> > >> >> >> > >>> No, at least I don't think so. The install/uninstall are more >> >> clobbers >> >> > >>> and plugin.xml is not a thing npm has any desire to become aware >> of. >> >> > >>> >> >> > >>> On Mon, Jul 29, 2013 at 11:24 PM, Andrew Grieve < >> >> agri...@chromium.org> >> >> > >>> wrote: >> >> > >>> > On Mon, Jul 29, 2013 at 11:19 PM, Brian LeRoux >> wrote: >> >> > >>> > >> >> > >>> >> > Would this require that we use the node_modules dependency >> >> > structure? >> >> > >>> >> >> >> > >>> >> No. We would teach npm install about our structure. >> >> > >>> >> >> >> > >>> >> >> >> > >>> >> > Would we be able to enforce our > >> cordova-version=">3.0.0"> >> >> > as >> >> > >>> well >> >> > >>> >> > as our > >> > >>> min-os-version="5.0"> >> >> > >>> >> > constraints? >> >> > >>> >> >> >> > >>> >> Yes. >> >> > >>> >> >> >> > >>> >> >> >> > >>> >> > Some things will be uglier to express as json I think. >> >> > >>> >> > E.g.: >> >> > trying to >> >> > >>> >> > embed xml snippets (like for ), that contain >> many " >> >> > >>> >> characters >> >> > >>> >> > and newline characters. >> >> > >>> >> >> >> > >>> >> Yes. >> >> > >>> >> >> >> > >>> >> >> >> > >>> >> > Making things harder to search for has been pointed out as >> >> > >>> >> > a >> >> > >>> >> disadvantage. >> >> > >>> >> > What would be the advantages? >> >> > >>> >> >> >> > >>> >> We implement a theoretically federated system. Cordova would >> >> > continue >> >> > >>> >> to use its own registry. (And thusly downstream distributions >> >> could >> >> > >>> >> use their own.) >> >> > >>> >> >> >> > >>> > >> >> > >>> > I thought this was already true with Anis' current setup? >> >> > >>> >> >> > >> >> >> > -- Regards, Sharif Ahmed Junior Software Engineer Therap Services, LLC +01715438290
Re: Plugin / Platform mismatch problems
Filed: https://issues.apache.org/jira/browse/CB-4477 On Wed, Jul 31, 2013 at 10:48 AM, Anis KADRI wrote: > I feel like we shouldn't. More source of errors than anything I think. > Also human readable names are useless when presented in search results > because one can't install using a human readable name. > > Shaz, I think we do need to add a doc issue. > > On Wed, Jul 31, 2013 at 10:30 AM, Andrew Grieve > wrote: > > I don't feel strongly one way or the other about prefixing. > > > > > > On Tue, Jul 30, 2013 at 6:49 PM, Shazron wrote: > > > >> Do we need to add a doc issue for updating this in 3.1: > >> 1. > >> > >> > http://cordova.apache.org/docs/en/3.0.0/plugin_ref_plugman.md.html#Using%20Plugman%20to%20Manage%20Plugins > >> 2. > >> > >> > http://cordova.apache.org/docs/en/3.0.0/guide_cli_index.md.html#The%20Command-line%20Interface > >> > >> (the docs will still work of course using the existing method) > >> > >> > >> On Tue, Jul 30, 2013 at 3:33 PM, Anis KADRI > wrote: > >> > >> > In the meantimeI renamed all plugins to package names in the > >> > cordova registry. I've also updated plugman > >> > > >> > So anyone should be able to `cordova plugin add > >> > org.apache.cordova.core.device` or `plugman install --platform > >> > platform --plugin org.apache.cordova.core.device --project > >> > /path/to/project` and it should just work. > >> > > >> > prefixing is not there yet. Do we really want it ? > >> > > >> > -a > >> > > >> > On Tue, Jul 30, 2013 at 9:58 AM, Brian LeRoux wrote: > >> > > Oh, yes, it could also be made to install from the npm registry. It > >> > > does neither of those things yet. > >> > > > >> > > On Tue, Jul 30, 2013 at 9:43 AM, Andrew Grieve < > agri...@chromium.org> > >> > wrote: > >> > >> A federated system just means that anyone can host a directory of > >> > plugins, > >> > >> yes? Anis was saying that plugman could be easily made to point at > any > >> > >> couchdb instance. Is that not federated? > >> > >> > >> > >> > >> > >> On Mon, Jul 29, 2013 at 11:38 PM, Brian LeRoux wrote: > >> > >> > >> > >>> No, at least I don't think so. The install/uninstall are more > >> clobbers > >> > >>> and plugin.xml is not a thing npm has any desire to become aware > of. > >> > >>> > >> > >>> On Mon, Jul 29, 2013 at 11:24 PM, Andrew Grieve < > >> agri...@chromium.org> > >> > >>> wrote: > >> > >>> > On Mon, Jul 29, 2013 at 11:19 PM, Brian LeRoux > wrote: > >> > >>> > > >> > >>> >> > Would this require that we use the node_modules dependency > >> > structure? > >> > >>> >> > >> > >>> >> No. We would teach npm install about our structure. > >> > >>> >> > >> > >>> >> > >> > >>> >> > Would we be able to enforce our >> cordova-version=">3.0.0"> > >> > as > >> > >>> well > >> > >>> >> > as our >> > >>> min-os-version="5.0"> > >> > >>> >> > constraints? > >> > >>> >> > >> > >>> >> Yes. > >> > >>> >> > >> > >>> >> > >> > >>> >> > Some things will be uglier to express as json I think. E.g.: > >> > trying to > >> > >>> >> > embed xml snippets (like for ), that contain > many " > >> > >>> >> characters > >> > >>> >> > and newline characters. > >> > >>> >> > >> > >>> >> Yes. > >> > >>> >> > >> > >>> >> > >> > >>> >> > Making things harder to search for has been pointed out as a > >> > >>> >> disadvantage. > >> > >>> >> > What would be the advantages? > >> > >>> >> > >> > >>> >> We implement a theoretically federated system. Cordova would > >> > continue > >> > >>> >> to use its own registry. (And thusly downstream distributions > >> could > >> > >>> >> use their own.) > >> > >>> >> > >> > >>> > > >> > >>> > I thought this was already true with Anis' current setup? > >> > >>> > >> > > >> >
Re: Plugin / Platform mismatch problems
I feel like we shouldn't. More source of errors than anything I think. Also human readable names are useless when presented in search results because one can't install using a human readable name. Shaz, I think we do need to add a doc issue. On Wed, Jul 31, 2013 at 10:30 AM, Andrew Grieve wrote: > I don't feel strongly one way or the other about prefixing. > > > On Tue, Jul 30, 2013 at 6:49 PM, Shazron wrote: > >> Do we need to add a doc issue for updating this in 3.1: >> 1. >> >> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_plugman.md.html#Using%20Plugman%20to%20Manage%20Plugins >> 2. >> >> http://cordova.apache.org/docs/en/3.0.0/guide_cli_index.md.html#The%20Command-line%20Interface >> >> (the docs will still work of course using the existing method) >> >> >> On Tue, Jul 30, 2013 at 3:33 PM, Anis KADRI wrote: >> >> > In the meantimeI renamed all plugins to package names in the >> > cordova registry. I've also updated plugman >> > >> > So anyone should be able to `cordova plugin add >> > org.apache.cordova.core.device` or `plugman install --platform >> > platform --plugin org.apache.cordova.core.device --project >> > /path/to/project` and it should just work. >> > >> > prefixing is not there yet. Do we really want it ? >> > >> > -a >> > >> > On Tue, Jul 30, 2013 at 9:58 AM, Brian LeRoux wrote: >> > > Oh, yes, it could also be made to install from the npm registry. It >> > > does neither of those things yet. >> > > >> > > On Tue, Jul 30, 2013 at 9:43 AM, Andrew Grieve >> > wrote: >> > >> A federated system just means that anyone can host a directory of >> > plugins, >> > >> yes? Anis was saying that plugman could be easily made to point at any >> > >> couchdb instance. Is that not federated? >> > >> >> > >> >> > >> On Mon, Jul 29, 2013 at 11:38 PM, Brian LeRoux wrote: >> > >> >> > >>> No, at least I don't think so. The install/uninstall are more >> clobbers >> > >>> and plugin.xml is not a thing npm has any desire to become aware of. >> > >>> >> > >>> On Mon, Jul 29, 2013 at 11:24 PM, Andrew Grieve < >> agri...@chromium.org> >> > >>> wrote: >> > >>> > On Mon, Jul 29, 2013 at 11:19 PM, Brian LeRoux wrote: >> > >>> > >> > >>> >> > Would this require that we use the node_modules dependency >> > structure? >> > >>> >> >> > >>> >> No. We would teach npm install about our structure. >> > >>> >> >> > >>> >> >> > >>> >> > Would we be able to enforce our > cordova-version=">3.0.0"> >> > as >> > >>> well >> > >>> >> > as our > > >>> min-os-version="5.0"> >> > >>> >> > constraints? >> > >>> >> >> > >>> >> Yes. >> > >>> >> >> > >>> >> >> > >>> >> > Some things will be uglier to express as json I think. E.g.: >> > trying to >> > >>> >> > embed xml snippets (like for ), that contain many " >> > >>> >> characters >> > >>> >> > and newline characters. >> > >>> >> >> > >>> >> Yes. >> > >>> >> >> > >>> >> >> > >>> >> > Making things harder to search for has been pointed out as a >> > >>> >> disadvantage. >> > >>> >> > What would be the advantages? >> > >>> >> >> > >>> >> We implement a theoretically federated system. Cordova would >> > continue >> > >>> >> to use its own registry. (And thusly downstream distributions >> could >> > >>> >> use their own.) >> > >>> >> >> > >>> > >> > >>> > I thought this was already true with Anis' current setup? >> > >>> >> > >>
Re: Plugin / Platform mismatch problems
I don't feel strongly one way or the other about prefixing. On Tue, Jul 30, 2013 at 6:49 PM, Shazron wrote: > Do we need to add a doc issue for updating this in 3.1: > 1. > > http://cordova.apache.org/docs/en/3.0.0/plugin_ref_plugman.md.html#Using%20Plugman%20to%20Manage%20Plugins > 2. > > http://cordova.apache.org/docs/en/3.0.0/guide_cli_index.md.html#The%20Command-line%20Interface > > (the docs will still work of course using the existing method) > > > On Tue, Jul 30, 2013 at 3:33 PM, Anis KADRI wrote: > > > In the meantimeI renamed all plugins to package names in the > > cordova registry. I've also updated plugman > > > > So anyone should be able to `cordova plugin add > > org.apache.cordova.core.device` or `plugman install --platform > > platform --plugin org.apache.cordova.core.device --project > > /path/to/project` and it should just work. > > > > prefixing is not there yet. Do we really want it ? > > > > -a > > > > On Tue, Jul 30, 2013 at 9:58 AM, Brian LeRoux wrote: > > > Oh, yes, it could also be made to install from the npm registry. It > > > does neither of those things yet. > > > > > > On Tue, Jul 30, 2013 at 9:43 AM, Andrew Grieve > > wrote: > > >> A federated system just means that anyone can host a directory of > > plugins, > > >> yes? Anis was saying that plugman could be easily made to point at any > > >> couchdb instance. Is that not federated? > > >> > > >> > > >> On Mon, Jul 29, 2013 at 11:38 PM, Brian LeRoux wrote: > > >> > > >>> No, at least I don't think so. The install/uninstall are more > clobbers > > >>> and plugin.xml is not a thing npm has any desire to become aware of. > > >>> > > >>> On Mon, Jul 29, 2013 at 11:24 PM, Andrew Grieve < > agri...@chromium.org> > > >>> wrote: > > >>> > On Mon, Jul 29, 2013 at 11:19 PM, Brian LeRoux wrote: > > >>> > > > >>> >> > Would this require that we use the node_modules dependency > > structure? > > >>> >> > > >>> >> No. We would teach npm install about our structure. > > >>> >> > > >>> >> > > >>> >> > Would we be able to enforce our cordova-version=">3.0.0"> > > as > > >>> well > > >>> >> > as our > >>> min-os-version="5.0"> > > >>> >> > constraints? > > >>> >> > > >>> >> Yes. > > >>> >> > > >>> >> > > >>> >> > Some things will be uglier to express as json I think. E.g.: > > trying to > > >>> >> > embed xml snippets (like for ), that contain many " > > >>> >> characters > > >>> >> > and newline characters. > > >>> >> > > >>> >> Yes. > > >>> >> > > >>> >> > > >>> >> > Making things harder to search for has been pointed out as a > > >>> >> disadvantage. > > >>> >> > What would be the advantages? > > >>> >> > > >>> >> We implement a theoretically federated system. Cordova would > > continue > > >>> >> to use its own registry. (And thusly downstream distributions > could > > >>> >> use their own.) > > >>> >> > > >>> > > > >>> > I thought this was already true with Anis' current setup? > > >>> > > >
Re: Plugin / Platform mismatch problems
Do we need to add a doc issue for updating this in 3.1: 1. http://cordova.apache.org/docs/en/3.0.0/plugin_ref_plugman.md.html#Using%20Plugman%20to%20Manage%20Plugins 2. http://cordova.apache.org/docs/en/3.0.0/guide_cli_index.md.html#The%20Command-line%20Interface (the docs will still work of course using the existing method) On Tue, Jul 30, 2013 at 3:33 PM, Anis KADRI wrote: > In the meantimeI renamed all plugins to package names in the > cordova registry. I've also updated plugman > > So anyone should be able to `cordova plugin add > org.apache.cordova.core.device` or `plugman install --platform > platform --plugin org.apache.cordova.core.device --project > /path/to/project` and it should just work. > > prefixing is not there yet. Do we really want it ? > > -a > > On Tue, Jul 30, 2013 at 9:58 AM, Brian LeRoux wrote: > > Oh, yes, it could also be made to install from the npm registry. It > > does neither of those things yet. > > > > On Tue, Jul 30, 2013 at 9:43 AM, Andrew Grieve > wrote: > >> A federated system just means that anyone can host a directory of > plugins, > >> yes? Anis was saying that plugman could be easily made to point at any > >> couchdb instance. Is that not federated? > >> > >> > >> On Mon, Jul 29, 2013 at 11:38 PM, Brian LeRoux wrote: > >> > >>> No, at least I don't think so. The install/uninstall are more clobbers > >>> and plugin.xml is not a thing npm has any desire to become aware of. > >>> > >>> On Mon, Jul 29, 2013 at 11:24 PM, Andrew Grieve > >>> wrote: > >>> > On Mon, Jul 29, 2013 at 11:19 PM, Brian LeRoux wrote: > >>> > > >>> >> > Would this require that we use the node_modules dependency > structure? > >>> >> > >>> >> No. We would teach npm install about our structure. > >>> >> > >>> >> > >>> >> > Would we be able to enforce our > as > >>> well > >>> >> > as our >>> min-os-version="5.0"> > >>> >> > constraints? > >>> >> > >>> >> Yes. > >>> >> > >>> >> > >>> >> > Some things will be uglier to express as json I think. E.g.: > trying to > >>> >> > embed xml snippets (like for ), that contain many " > >>> >> characters > >>> >> > and newline characters. > >>> >> > >>> >> Yes. > >>> >> > >>> >> > >>> >> > Making things harder to search for has been pointed out as a > >>> >> disadvantage. > >>> >> > What would be the advantages? > >>> >> > >>> >> We implement a theoretically federated system. Cordova would > continue > >>> >> to use its own registry. (And thusly downstream distributions could > >>> >> use their own.) > >>> >> > >>> > > >>> > I thought this was already true with Anis' current setup? > >>> >
Re: Plugin / Platform mismatch problems
In the meantimeI renamed all plugins to package names in the cordova registry. I've also updated plugman So anyone should be able to `cordova plugin add org.apache.cordova.core.device` or `plugman install --platform platform --plugin org.apache.cordova.core.device --project /path/to/project` and it should just work. prefixing is not there yet. Do we really want it ? -a On Tue, Jul 30, 2013 at 9:58 AM, Brian LeRoux wrote: > Oh, yes, it could also be made to install from the npm registry. It > does neither of those things yet. > > On Tue, Jul 30, 2013 at 9:43 AM, Andrew Grieve wrote: >> A federated system just means that anyone can host a directory of plugins, >> yes? Anis was saying that plugman could be easily made to point at any >> couchdb instance. Is that not federated? >> >> >> On Mon, Jul 29, 2013 at 11:38 PM, Brian LeRoux wrote: >> >>> No, at least I don't think so. The install/uninstall are more clobbers >>> and plugin.xml is not a thing npm has any desire to become aware of. >>> >>> On Mon, Jul 29, 2013 at 11:24 PM, Andrew Grieve >>> wrote: >>> > On Mon, Jul 29, 2013 at 11:19 PM, Brian LeRoux wrote: >>> > >>> >> > Would this require that we use the node_modules dependency structure? >>> >> >>> >> No. We would teach npm install about our structure. >>> >> >>> >> >>> >> > Would we be able to enforce our as >>> well >>> >> > as our >> min-os-version="5.0"> >>> >> > constraints? >>> >> >>> >> Yes. >>> >> >>> >> >>> >> > Some things will be uglier to express as json I think. E.g.: trying to >>> >> > embed xml snippets (like for ), that contain many " >>> >> characters >>> >> > and newline characters. >>> >> >>> >> Yes. >>> >> >>> >> >>> >> > Making things harder to search for has been pointed out as a >>> >> disadvantage. >>> >> > What would be the advantages? >>> >> >>> >> We implement a theoretically federated system. Cordova would continue >>> >> to use its own registry. (And thusly downstream distributions could >>> >> use their own.) >>> >> >>> > >>> > I thought this was already true with Anis' current setup? >>>
Re: Plugin / Platform mismatch problems
Oh, yes, it could also be made to install from the npm registry. It does neither of those things yet. On Tue, Jul 30, 2013 at 9:43 AM, Andrew Grieve wrote: > A federated system just means that anyone can host a directory of plugins, > yes? Anis was saying that plugman could be easily made to point at any > couchdb instance. Is that not federated? > > > On Mon, Jul 29, 2013 at 11:38 PM, Brian LeRoux wrote: > >> No, at least I don't think so. The install/uninstall are more clobbers >> and plugin.xml is not a thing npm has any desire to become aware of. >> >> On Mon, Jul 29, 2013 at 11:24 PM, Andrew Grieve >> wrote: >> > On Mon, Jul 29, 2013 at 11:19 PM, Brian LeRoux wrote: >> > >> >> > Would this require that we use the node_modules dependency structure? >> >> >> >> No. We would teach npm install about our structure. >> >> >> >> >> >> > Would we be able to enforce our as >> well >> >> > as our > min-os-version="5.0"> >> >> > constraints? >> >> >> >> Yes. >> >> >> >> >> >> > Some things will be uglier to express as json I think. E.g.: trying to >> >> > embed xml snippets (like for ), that contain many " >> >> characters >> >> > and newline characters. >> >> >> >> Yes. >> >> >> >> >> >> > Making things harder to search for has been pointed out as a >> >> disadvantage. >> >> > What would be the advantages? >> >> >> >> We implement a theoretically federated system. Cordova would continue >> >> to use its own registry. (And thusly downstream distributions could >> >> use their own.) >> >> >> > >> > I thought this was already true with Anis' current setup? >>
Re: Plugin / Platform mismatch problems
A federated system just means that anyone can host a directory of plugins, yes? Anis was saying that plugman could be easily made to point at any couchdb instance. Is that not federated? On Mon, Jul 29, 2013 at 11:38 PM, Brian LeRoux wrote: > No, at least I don't think so. The install/uninstall are more clobbers > and plugin.xml is not a thing npm has any desire to become aware of. > > On Mon, Jul 29, 2013 at 11:24 PM, Andrew Grieve > wrote: > > On Mon, Jul 29, 2013 at 11:19 PM, Brian LeRoux wrote: > > > >> > Would this require that we use the node_modules dependency structure? > >> > >> No. We would teach npm install about our structure. > >> > >> > >> > Would we be able to enforce our as > well > >> > as our min-os-version="5.0"> > >> > constraints? > >> > >> Yes. > >> > >> > >> > Some things will be uglier to express as json I think. E.g.: trying to > >> > embed xml snippets (like for ), that contain many " > >> characters > >> > and newline characters. > >> > >> Yes. > >> > >> > >> > Making things harder to search for has been pointed out as a > >> disadvantage. > >> > What would be the advantages? > >> > >> We implement a theoretically federated system. Cordova would continue > >> to use its own registry. (And thusly downstream distributions could > >> use their own.) > >> > > > > I thought this was already true with Anis' current setup? >
Re: Plugin / Platform mismatch problems
No, at least I don't think so. The install/uninstall are more clobbers and plugin.xml is not a thing npm has any desire to become aware of. On Mon, Jul 29, 2013 at 11:24 PM, Andrew Grieve wrote: > On Mon, Jul 29, 2013 at 11:19 PM, Brian LeRoux wrote: > >> > Would this require that we use the node_modules dependency structure? >> >> No. We would teach npm install about our structure. >> >> >> > Would we be able to enforce our as well >> > as our >> > constraints? >> >> Yes. >> >> >> > Some things will be uglier to express as json I think. E.g.: trying to >> > embed xml snippets (like for ), that contain many " >> characters >> > and newline characters. >> >> Yes. >> >> >> > Making things harder to search for has been pointed out as a >> disadvantage. >> > What would be the advantages? >> >> We implement a theoretically federated system. Cordova would continue >> to use its own registry. (And thusly downstream distributions could >> use their own.) >> > > I thought this was already true with Anis' current setup?
Re: Plugin / Platform mismatch problems
On Mon, Jul 29, 2013 at 11:19 PM, Brian LeRoux wrote: > > Would this require that we use the node_modules dependency structure? > > No. We would teach npm install about our structure. > > > > Would we be able to enforce our as well > > as our > > constraints? > > Yes. > > > > Some things will be uglier to express as json I think. E.g.: trying to > > embed xml snippets (like for ), that contain many " > characters > > and newline characters. > > Yes. > > > > Making things harder to search for has been pointed out as a > disadvantage. > > What would be the advantages? > > We implement a theoretically federated system. Cordova would continue > to use its own registry. (And thusly downstream distributions could > use their own.) > I thought this was already true with Anis' current setup?
Re: Plugin / Platform mismatch problems
> Would this require that we use the node_modules dependency structure? No. We would teach npm install about our structure. > Would we be able to enforce our as well > as our > constraints? Yes. > Some things will be uglier to express as json I think. E.g.: trying to > embed xml snippets (like for ), that contain many " characters > and newline characters. Yes. > Making things harder to search for has been pointed out as a disadvantage. > What would be the advantages? We implement a theoretically federated system. Cordova would continue to use its own registry. (And thusly downstream distributions could use their own.)
Re: Plugin / Platform mismatch problems
Would this require that we use the node_modules dependency structure? e.g. Our dependency system works differently from node's. We don't support A depends on B-v1 and C depends on B-v2. Would we be able to enforce our as well as our constraints? Some things will be uglier to express as json I think. E.g.: trying to embed xml snippets (like for ), that contain many " characters and newline characters. Making things harder to search for has been pointed out as a disadvantage. What would be the advantages? On Mon, Jul 29, 2013 at 9:00 PM, Filip Maj wrote: > Compatibility with npm sounds great and I fully support it. > > We still need to be conscious of old plugin.xml compatibility, though > > Interesting thing there is putting plugman or cordova-cli into plugins' > package.json as dependencies, which would give you all tools you need to > do cool things like auto-installation > > On 7/29/13 4:55 PM, "Brian LeRoux" wrote: > > >Ya, the Node characters in this story that I'm talking w/ are dshaw, > >mikeal, izs, and joemccann. All pushing we go this route and YES its > >super easier than it sounds. =P > > > >Agree on discovery getting a little harder but this isn't an exclusive > >move but rather an additive operation. That is to say, they want us to > >have a compatibility but in no way are saying we use the npm registry > >for our core plugins. > > > >So: package.json, install, and uninstall are the tricks to this pony. > >I think we can easily get consensus for moving to package.json using > >our current technique. I'll talk to them further about the > >install/uninstall business. > > > >The next version of Node will be shipping w/ the npm registry included > >so this is actually rather cool for us as the install would become: > >install node. > > > > > >On Mon, Jul 29, 2013 at 7:41 PM, Anis KADRI wrote: > >> I spoke with @dshaw about this and told him why it was (currently) not > >> an option for Cordova. > >> > >> Specifically (un)install actions and dependency management are > >> different. It seems like a a lot of overhead to get npm to do what > >> plugman (un)install does. > >> > >> Everything else is pretty much the same and moving from plugin.xml to > >> package.json won't hurt us I don't think. I guess we wouldn't be able > >> to do XSLTs to validate documents but...other than that it would be a > >> logical move. > >> > >> The other thing too is that npm is mainly for nodejs and/or javascript > >> packages and getting Cordova plugins in there can make search and > >> discovery harder. There are currently 36,472 NPMs as of this writing. > >> The counter-argument to this is that there are npm modules that use > >> native codes to execute. Some of them even require some third-party > >> interpreters (Ruby, Python, etc...). > >> > >> On Mon, Jul 29, 2013 at 4:28 PM, Brian LeRoux wrote: > >>> I have a parallel conversation rolling w/ the node guys and they're > >>> hoping to convince us to move everything to the npm registry itself. > >>> (Or at least be compatible to do so.) > >>> > >>> I think this is a worthwhile goal but it does mean: > >>> > >>> - plugin.xml gets either deprecated for package.json or we continue > >>> tool that impedance mismatch > >>> - install on the npm side needs to learn about cordova (yes issac is > >>> open to this!) > >>> > >>> Did I miss anything Anis? > >>> > >>> Thoughts [larger group]? > >>> > >>> > >>> > >>> On Mon, Jul 29, 2013 at 6:06 PM, Anis KADRI > >>>wrote: > Agree. > For the last point. There is a tag added to the spec to > facilitate search. Has to be added by plugin author. > I am going to drop the current names for the registry and republish > them with the new convention. Unless anyone has any objections. We'll > implement that prefixing right after. > > On Mon, Jul 29, 2013 at 2:55 PM, Filip Maj wrote: > > I think what would work is: > > > > - use ids to uniquely identify > > - prepending org.apache.cordova.core or w/e our core plugin > >namespace is > > as a fallback attempt to match makes sense > > - finally, for discovery/searching, we should do searches vs a > >plugin's > > field and do our best to enforce good descriptions on > > plugins being submitted to the apache cordova registry > > > > On 7/29/13 1:13 PM, "Anis KADRI" wrote: > > > >>Right but npm registry uses JSON not XML. I think prefixing core > >>plugins when no package name is provided is a good idea. > >> > >>On Mon, Jul 29, 2013 at 1:08 PM, Marcel Kinard > >>wrote: > >>> That could be accomplished with XSLT. And XPath has basic query > >>>capability. James Jong and I have skills in those. > >>> > >>> On Jul 26, 2013, at 2:19 PM, Filip Maj wrote: > >>> > Ahh yeah. Some kind of at-publish-time conversion of certain > plugin.xml > fields to json fields? > > On 7/26/13 10:27 AM, "Anis KADRI" wrote: >
Re: Plugin / Platform mismatch problems
Compatibility with npm sounds great and I fully support it. We still need to be conscious of old plugin.xml compatibility, though Interesting thing there is putting plugman or cordova-cli into plugins' package.json as dependencies, which would give you all tools you need to do cool things like auto-installation On 7/29/13 4:55 PM, "Brian LeRoux" wrote: >Ya, the Node characters in this story that I'm talking w/ are dshaw, >mikeal, izs, and joemccann. All pushing we go this route and YES its >super easier than it sounds. =P > >Agree on discovery getting a little harder but this isn't an exclusive >move but rather an additive operation. That is to say, they want us to >have a compatibility but in no way are saying we use the npm registry >for our core plugins. > >So: package.json, install, and uninstall are the tricks to this pony. >I think we can easily get consensus for moving to package.json using >our current technique. I'll talk to them further about the >install/uninstall business. > >The next version of Node will be shipping w/ the npm registry included >so this is actually rather cool for us as the install would become: >install node. > > >On Mon, Jul 29, 2013 at 7:41 PM, Anis KADRI wrote: >> I spoke with @dshaw about this and told him why it was (currently) not >> an option for Cordova. >> >> Specifically (un)install actions and dependency management are >> different. It seems like a a lot of overhead to get npm to do what >> plugman (un)install does. >> >> Everything else is pretty much the same and moving from plugin.xml to >> package.json won't hurt us I don't think. I guess we wouldn't be able >> to do XSLTs to validate documents but...other than that it would be a >> logical move. >> >> The other thing too is that npm is mainly for nodejs and/or javascript >> packages and getting Cordova plugins in there can make search and >> discovery harder. There are currently 36,472 NPMs as of this writing. >> The counter-argument to this is that there are npm modules that use >> native codes to execute. Some of them even require some third-party >> interpreters (Ruby, Python, etc...). >> >> On Mon, Jul 29, 2013 at 4:28 PM, Brian LeRoux wrote: >>> I have a parallel conversation rolling w/ the node guys and they're >>> hoping to convince us to move everything to the npm registry itself. >>> (Or at least be compatible to do so.) >>> >>> I think this is a worthwhile goal but it does mean: >>> >>> - plugin.xml gets either deprecated for package.json or we continue >>> tool that impedance mismatch >>> - install on the npm side needs to learn about cordova (yes issac is >>> open to this!) >>> >>> Did I miss anything Anis? >>> >>> Thoughts [larger group]? >>> >>> >>> >>> On Mon, Jul 29, 2013 at 6:06 PM, Anis KADRI >>>wrote: Agree. For the last point. There is a tag added to the spec to facilitate search. Has to be added by plugin author. I am going to drop the current names for the registry and republish them with the new convention. Unless anyone has any objections. We'll implement that prefixing right after. On Mon, Jul 29, 2013 at 2:55 PM, Filip Maj wrote: > I think what would work is: > > - use ids to uniquely identify > - prepending org.apache.cordova.core or w/e our core plugin >namespace is > as a fallback attempt to match makes sense > - finally, for discovery/searching, we should do searches vs a >plugin's > field and do our best to enforce good descriptions on > plugins being submitted to the apache cordova registry > > On 7/29/13 1:13 PM, "Anis KADRI" wrote: > >>Right but npm registry uses JSON not XML. I think prefixing core >>plugins when no package name is provided is a good idea. >> >>On Mon, Jul 29, 2013 at 1:08 PM, Marcel Kinard >>wrote: >>> That could be accomplished with XSLT. And XPath has basic query >>>capability. James Jong and I have skills in those. >>> >>> On Jul 26, 2013, at 2:19 PM, Filip Maj wrote: >>> Ahh yeah. Some kind of at-publish-time conversion of certain plugin.xml fields to json fields? On 7/26/13 10:27 AM, "Anis KADRI" wrote: > I think XML is not a query friendly language. I suggest we add an > engine field initially and then add fields as we need them. I >suspect > we won't be needing the bulk of plugin.xml in the registry. I >have to > experiment with custom fields still but it seems possible. I will > report back sometime today. >>> >
Re: Plugin / Platform mismatch problems
Ya, the Node characters in this story that I'm talking w/ are dshaw, mikeal, izs, and joemccann. All pushing we go this route and YES its super easier than it sounds. =P Agree on discovery getting a little harder but this isn't an exclusive move but rather an additive operation. That is to say, they want us to have a compatibility but in no way are saying we use the npm registry for our core plugins. So: package.json, install, and uninstall are the tricks to this pony. I think we can easily get consensus for moving to package.json using our current technique. I'll talk to them further about the install/uninstall business. The next version of Node will be shipping w/ the npm registry included so this is actually rather cool for us as the install would become: install node. On Mon, Jul 29, 2013 at 7:41 PM, Anis KADRI wrote: > I spoke with @dshaw about this and told him why it was (currently) not > an option for Cordova. > > Specifically (un)install actions and dependency management are > different. It seems like a a lot of overhead to get npm to do what > plugman (un)install does. > > Everything else is pretty much the same and moving from plugin.xml to > package.json won't hurt us I don't think. I guess we wouldn't be able > to do XSLTs to validate documents but...other than that it would be a > logical move. > > The other thing too is that npm is mainly for nodejs and/or javascript > packages and getting Cordova plugins in there can make search and > discovery harder. There are currently 36,472 NPMs as of this writing. > The counter-argument to this is that there are npm modules that use > native codes to execute. Some of them even require some third-party > interpreters (Ruby, Python, etc...). > > On Mon, Jul 29, 2013 at 4:28 PM, Brian LeRoux wrote: >> I have a parallel conversation rolling w/ the node guys and they're >> hoping to convince us to move everything to the npm registry itself. >> (Or at least be compatible to do so.) >> >> I think this is a worthwhile goal but it does mean: >> >> - plugin.xml gets either deprecated for package.json or we continue >> tool that impedance mismatch >> - install on the npm side needs to learn about cordova (yes issac is >> open to this!) >> >> Did I miss anything Anis? >> >> Thoughts [larger group]? >> >> >> >> On Mon, Jul 29, 2013 at 6:06 PM, Anis KADRI wrote: >>> Agree. >>> For the last point. There is a tag added to the spec to >>> facilitate search. Has to be added by plugin author. >>> I am going to drop the current names for the registry and republish >>> them with the new convention. Unless anyone has any objections. We'll >>> implement that prefixing right after. >>> >>> On Mon, Jul 29, 2013 at 2:55 PM, Filip Maj wrote: I think what would work is: - use ids to uniquely identify - prepending org.apache.cordova.core or w/e our core plugin namespace is as a fallback attempt to match makes sense - finally, for discovery/searching, we should do searches vs a plugin's field and do our best to enforce good descriptions on plugins being submitted to the apache cordova registry On 7/29/13 1:13 PM, "Anis KADRI" wrote: >Right but npm registry uses JSON not XML. I think prefixing core >plugins when no package name is provided is a good idea. > >On Mon, Jul 29, 2013 at 1:08 PM, Marcel Kinard wrote: >> That could be accomplished with XSLT. And XPath has basic query >>capability. James Jong and I have skills in those. >> >> On Jul 26, 2013, at 2:19 PM, Filip Maj wrote: >> >>> Ahh yeah. Some kind of at-publish-time conversion of certain plugin.xml >>> fields to json fields? >>> >>> On 7/26/13 10:27 AM, "Anis KADRI" wrote: >>> I think XML is not a query friendly language. I suggest we add an engine field initially and then add fields as we need them. I suspect we won't be needing the bulk of plugin.xml in the registry. I have to experiment with custom fields still but it seems possible. I will report back sometime today. >>
Re: Plugin / Platform mismatch problems
I spoke with @dshaw about this and told him why it was (currently) not an option for Cordova. Specifically (un)install actions and dependency management are different. It seems like a a lot of overhead to get npm to do what plugman (un)install does. Everything else is pretty much the same and moving from plugin.xml to package.json won't hurt us I don't think. I guess we wouldn't be able to do XSLTs to validate documents but...other than that it would be a logical move. The other thing too is that npm is mainly for nodejs and/or javascript packages and getting Cordova plugins in there can make search and discovery harder. There are currently 36,472 NPMs as of this writing. The counter-argument to this is that there are npm modules that use native codes to execute. Some of them even require some third-party interpreters (Ruby, Python, etc...). On Mon, Jul 29, 2013 at 4:28 PM, Brian LeRoux wrote: > I have a parallel conversation rolling w/ the node guys and they're > hoping to convince us to move everything to the npm registry itself. > (Or at least be compatible to do so.) > > I think this is a worthwhile goal but it does mean: > > - plugin.xml gets either deprecated for package.json or we continue > tool that impedance mismatch > - install on the npm side needs to learn about cordova (yes issac is > open to this!) > > Did I miss anything Anis? > > Thoughts [larger group]? > > > > On Mon, Jul 29, 2013 at 6:06 PM, Anis KADRI wrote: >> Agree. >> For the last point. There is a tag added to the spec to >> facilitate search. Has to be added by plugin author. >> I am going to drop the current names for the registry and republish >> them with the new convention. Unless anyone has any objections. We'll >> implement that prefixing right after. >> >> On Mon, Jul 29, 2013 at 2:55 PM, Filip Maj wrote: >>> I think what would work is: >>> >>> - use ids to uniquely identify >>> - prepending org.apache.cordova.core or w/e our core plugin namespace is >>> as a fallback attempt to match makes sense >>> - finally, for discovery/searching, we should do searches vs a plugin's >>> field and do our best to enforce good descriptions on >>> plugins being submitted to the apache cordova registry >>> >>> On 7/29/13 1:13 PM, "Anis KADRI" wrote: >>> Right but npm registry uses JSON not XML. I think prefixing core plugins when no package name is provided is a good idea. On Mon, Jul 29, 2013 at 1:08 PM, Marcel Kinard wrote: > That could be accomplished with XSLT. And XPath has basic query >capability. James Jong and I have skills in those. > > On Jul 26, 2013, at 2:19 PM, Filip Maj wrote: > >> Ahh yeah. Some kind of at-publish-time conversion of certain plugin.xml >> fields to json fields? >> >> On 7/26/13 10:27 AM, "Anis KADRI" wrote: >> >>> I think XML is not a query friendly language. I suggest we add an >>> engine field initially and then add fields as we need them. I suspect >>> we won't be needing the bulk of plugin.xml in the registry. I have to >>> experiment with custom fields still but it seems possible. I will >>> report back sometime today. > >>>
Re: Plugin / Platform mismatch problems
I have a parallel conversation rolling w/ the node guys and they're hoping to convince us to move everything to the npm registry itself. (Or at least be compatible to do so.) I think this is a worthwhile goal but it does mean: - plugin.xml gets either deprecated for package.json or we continue tool that impedance mismatch - install on the npm side needs to learn about cordova (yes issac is open to this!) Did I miss anything Anis? Thoughts [larger group]? On Mon, Jul 29, 2013 at 6:06 PM, Anis KADRI wrote: > Agree. > For the last point. There is a tag added to the spec to > facilitate search. Has to be added by plugin author. > I am going to drop the current names for the registry and republish > them with the new convention. Unless anyone has any objections. We'll > implement that prefixing right after. > > On Mon, Jul 29, 2013 at 2:55 PM, Filip Maj wrote: >> I think what would work is: >> >> - use ids to uniquely identify >> - prepending org.apache.cordova.core or w/e our core plugin namespace is >> as a fallback attempt to match makes sense >> - finally, for discovery/searching, we should do searches vs a plugin's >> field and do our best to enforce good descriptions on >> plugins being submitted to the apache cordova registry >> >> On 7/29/13 1:13 PM, "Anis KADRI" wrote: >> >>>Right but npm registry uses JSON not XML. I think prefixing core >>>plugins when no package name is provided is a good idea. >>> >>>On Mon, Jul 29, 2013 at 1:08 PM, Marcel Kinard wrote: That could be accomplished with XSLT. And XPath has basic query capability. James Jong and I have skills in those. On Jul 26, 2013, at 2:19 PM, Filip Maj wrote: > Ahh yeah. Some kind of at-publish-time conversion of certain plugin.xml > fields to json fields? > > On 7/26/13 10:27 AM, "Anis KADRI" wrote: > >> I think XML is not a query friendly language. I suggest we add an >> engine field initially and then add fields as we need them. I suspect >> we won't be needing the bulk of plugin.xml in the registry. I have to >> experiment with custom fields still but it seems possible. I will >> report back sometime today. >>
Re: Plugin / Platform mismatch problems
Agree. For the last point. There is a tag added to the spec to facilitate search. Has to be added by plugin author. I am going to drop the current names for the registry and republish them with the new convention. Unless anyone has any objections. We'll implement that prefixing right after. On Mon, Jul 29, 2013 at 2:55 PM, Filip Maj wrote: > I think what would work is: > > - use ids to uniquely identify > - prepending org.apache.cordova.core or w/e our core plugin namespace is > as a fallback attempt to match makes sense > - finally, for discovery/searching, we should do searches vs a plugin's > field and do our best to enforce good descriptions on > plugins being submitted to the apache cordova registry > > On 7/29/13 1:13 PM, "Anis KADRI" wrote: > >>Right but npm registry uses JSON not XML. I think prefixing core >>plugins when no package name is provided is a good idea. >> >>On Mon, Jul 29, 2013 at 1:08 PM, Marcel Kinard wrote: >>> That could be accomplished with XSLT. And XPath has basic query >>>capability. James Jong and I have skills in those. >>> >>> On Jul 26, 2013, at 2:19 PM, Filip Maj wrote: >>> Ahh yeah. Some kind of at-publish-time conversion of certain plugin.xml fields to json fields? On 7/26/13 10:27 AM, "Anis KADRI" wrote: > I think XML is not a query friendly language. I suggest we add an > engine field initially and then add fields as we need them. I suspect > we won't be needing the bulk of plugin.xml in the registry. I have to > experiment with custom fields still but it seems possible. I will > report back sometime today. >>> >
Re: Plugin / Platform mismatch problems
I think what would work is: - use ids to uniquely identify - prepending org.apache.cordova.core or w/e our core plugin namespace is as a fallback attempt to match makes sense - finally, for discovery/searching, we should do searches vs a plugin's field and do our best to enforce good descriptions on plugins being submitted to the apache cordova registry On 7/29/13 1:13 PM, "Anis KADRI" wrote: >Right but npm registry uses JSON not XML. I think prefixing core >plugins when no package name is provided is a good idea. > >On Mon, Jul 29, 2013 at 1:08 PM, Marcel Kinard wrote: >> That could be accomplished with XSLT. And XPath has basic query >>capability. James Jong and I have skills in those. >> >> On Jul 26, 2013, at 2:19 PM, Filip Maj wrote: >> >>> Ahh yeah. Some kind of at-publish-time conversion of certain plugin.xml >>> fields to json fields? >>> >>> On 7/26/13 10:27 AM, "Anis KADRI" wrote: >>> I think XML is not a query friendly language. I suggest we add an engine field initially and then add fields as we need them. I suspect we won't be needing the bulk of plugin.xml in the registry. I have to experiment with custom fields still but it seems possible. I will report back sometime today. >>
Re: Plugin / Platform mismatch problems
Right but npm registry uses JSON not XML. I think prefixing core plugins when no package name is provided is a good idea. On Mon, Jul 29, 2013 at 1:08 PM, Marcel Kinard wrote: > That could be accomplished with XSLT. And XPath has basic query capability. > James Jong and I have skills in those. > > On Jul 26, 2013, at 2:19 PM, Filip Maj wrote: > >> Ahh yeah. Some kind of at-publish-time conversion of certain plugin.xml >> fields to json fields? >> >> On 7/26/13 10:27 AM, "Anis KADRI" wrote: >> >>> I think XML is not a query friendly language. I suggest we add an >>> engine field initially and then add fields as we need them. I suspect >>> we won't be needing the bulk of plugin.xml in the registry. I have to >>> experiment with custom fields still but it seems possible. I will >>> report back sometime today. >
Re: Plugin / Platform mismatch problems
That could be accomplished with XSLT. And XPath has basic query capability. James Jong and I have skills in those. On Jul 26, 2013, at 2:19 PM, Filip Maj wrote: > Ahh yeah. Some kind of at-publish-time conversion of certain plugin.xml > fields to json fields? > > On 7/26/13 10:27 AM, "Anis KADRI" wrote: > >> I think XML is not a query friendly language. I suggest we add an >> engine field initially and then add fields as we need them. I suspect >> we won't be needing the bulk of plugin.xml in the registry. I have to >> experiment with custom fields still but it seems possible. I will >> report back sometime today.
Re: Plugin / Platform mismatch problems
That is not a bad idea. We would just need to update the uninstall action to support that "prefix" as well. I like the use of id for its uniqueness, it's just not as user-friendly as just typing a name. On Mon, Jul 29, 2013 at 12:10 PM, Andrew Grieve wrote: > Great summary Fil. > > Sounds to me like what we should do is use the id for the npm "name". > For the lazy, we could special-case core plugins, so that if you leave off > the fqn, plugman will prepend "org.apache.cordova.core". > > > On Mon, Jul 29, 2013 at 3:02 PM, Filip Maj wrote: > >> I'll try to summarize where we were before and where we are at currently. >> >> In The Beginning: >> - we spec'ed an `id` attribute to the plugin manifest under the pretense >> of having a unique identifier (generally a good idea), and a preemptive >> approach at easing a situation where we have a multi-registry universe >> (For example: BlackBerry, Apache, Google all hosting plugin registries) >> - the element was to be a human-readable, "pretty" label. It can >> have spaces, apostrophes, etc. just like the element in config.xml >> >> In The Present: >> - we are at the point where we are using an existing system (npm) that has >> different constraints on uniquely identifying a project. Npm uses a name, >> with no spaces, no underscores, and some other char constraints. >> - which leads us to our current conundrum: which field do we use to >> uniquely identify a plugin, and which solution should we employ to map >> between our plugin specification for naming / id'ing packages vs. Npm's. >> >> There are many different ways to solve this problem, each with varying >> degrees of difficulty to implement and each having a different answer to >> the question of "how much will we need to diverge from npm to support it": >> >> - using a plugin id as the npm "name" >> - using a plugin's "cleaned up" contents (no spaces or funny >> characters) as the npm name >> >> Finally, discovery is the last use case that needs to be addressed here. >> What is npm's current strategy and what do we want to support? >> >> On 7/26/13 11:21 AM, "Anis KADRI" wrote: >> >> >Exactly! Only the ones we need too! We're already doing this for >> >name/version/description so it would just be a few more. >> > >> >On Fri, Jul 26, 2013 at 11:19 AM, Filip Maj wrote: >> >> Ahh yeah. Some kind of at-publish-time conversion of certain plugin.xml >> >> fields to json fields? >> >> >> >> On 7/26/13 10:27 AM, "Anis KADRI" wrote: >> >> >> >>>I think XML is not a query friendly language. I suggest we add an >> >>>engine field initially and then add fields as we need them. I suspect >> >>>we won't be needing the bulk of plugin.xml in the registry. I have to >> >>>experiment with custom fields still but it seems possible. I will >> >>>report back sometime today. >> >>> >> >>>On Fri, Jul 26, 2013 at 9:23 AM, Filip Maj wrote: >> I think this was brought up before, but why not store the plugin xml >> in >> its entirety? I can us needing more bits down the road, such as >> dependencies and platform version requirements. >> >> >> On 7/26/13 7:32 AM, "Andrew Grieve" wrote: >> >> >That all sounds good, but let's talk more about the git ref part: >> > >> >It looks like our npm-based directory system is going to host the .tgz >> >of >> >the plugins, so it won't matter what git ref the .tgz maps back to >> >unless >> >we think that a lot of people are not going to use our directory >> >service. >> > >> >One thing that would be useful though, is a way to list plugins >> >compatible >> >with your version of cordova (e.g. query for the latest version of >> >cordova-plugin-file that is compatible with 3.0.0). I think all that's >> >required here is to store the engine tag in the couchdb metadata >> >alongside >> >the tgz. >> > >> > >> >On Thu, Jul 25, 2013 at 6:38 PM, Benn Mapes >> >wrote: >> > >> >> +1 to brett's comments. >> >> Name - Human Readable name of the plugin to be used in the context >> >>of >> >> plugin >> >> discovery. >> >> ID - unique id used by tools to reference the plugin >> >> Description - sentence+ about the plugin (optional?) >> >> >> >> As for how plugins should be loaded I liked Braden's suggestion that >> >>plugin >> >> authors decide what the default ref is for their plugin. Default >> >>should >> >>be >> >> master if no ref is provided. >> >> >> >> >> >> On Thu, Jul 25, 2013 at 1:27 PM, Steven Gill >> >> >> >> wrote: >> >> >> >> > I am going to hold off on testing + deploying+ merging this back >> >>in >> >>until >> >> > we get some sort of consensus on naming >> >> > >> >> > >> >> > On Thu, Jul 25, 2013 at 12:10 PM, RUDD, Brett >> >> >> >> wrote: >> >> > >> >> > > name is human readable and should be retained for plugin >> >>discovery >>
Re: Plugin / Platform mismatch problems
Great summary Fil. Sounds to me like what we should do is use the id for the npm "name". For the lazy, we could special-case core plugins, so that if you leave off the fqn, plugman will prepend "org.apache.cordova.core". On Mon, Jul 29, 2013 at 3:02 PM, Filip Maj wrote: > I'll try to summarize where we were before and where we are at currently. > > In The Beginning: > - we spec'ed an `id` attribute to the plugin manifest under the pretense > of having a unique identifier (generally a good idea), and a preemptive > approach at easing a situation where we have a multi-registry universe > (For example: BlackBerry, Apache, Google all hosting plugin registries) > - the element was to be a human-readable, "pretty" label. It can > have spaces, apostrophes, etc. just like the element in config.xml > > In The Present: > - we are at the point where we are using an existing system (npm) that has > different constraints on uniquely identifying a project. Npm uses a name, > with no spaces, no underscores, and some other char constraints. > - which leads us to our current conundrum: which field do we use to > uniquely identify a plugin, and which solution should we employ to map > between our plugin specification for naming / id'ing packages vs. Npm's. > > There are many different ways to solve this problem, each with varying > degrees of difficulty to implement and each having a different answer to > the question of "how much will we need to diverge from npm to support it": > > - using a plugin id as the npm "name" > - using a plugin's "cleaned up" contents (no spaces or funny > characters) as the npm name > > Finally, discovery is the last use case that needs to be addressed here. > What is npm's current strategy and what do we want to support? > > On 7/26/13 11:21 AM, "Anis KADRI" wrote: > > >Exactly! Only the ones we need too! We're already doing this for > >name/version/description so it would just be a few more. > > > >On Fri, Jul 26, 2013 at 11:19 AM, Filip Maj wrote: > >> Ahh yeah. Some kind of at-publish-time conversion of certain plugin.xml > >> fields to json fields? > >> > >> On 7/26/13 10:27 AM, "Anis KADRI" wrote: > >> > >>>I think XML is not a query friendly language. I suggest we add an > >>>engine field initially and then add fields as we need them. I suspect > >>>we won't be needing the bulk of plugin.xml in the registry. I have to > >>>experiment with custom fields still but it seems possible. I will > >>>report back sometime today. > >>> > >>>On Fri, Jul 26, 2013 at 9:23 AM, Filip Maj wrote: > I think this was brought up before, but why not store the plugin xml > in > its entirety? I can us needing more bits down the road, such as > dependencies and platform version requirements. > > > On 7/26/13 7:32 AM, "Andrew Grieve" wrote: > > >That all sounds good, but let's talk more about the git ref part: > > > >It looks like our npm-based directory system is going to host the .tgz > >of > >the plugins, so it won't matter what git ref the .tgz maps back to > >unless > >we think that a lot of people are not going to use our directory > >service. > > > >One thing that would be useful though, is a way to list plugins > >compatible > >with your version of cordova (e.g. query for the latest version of > >cordova-plugin-file that is compatible with 3.0.0). I think all that's > >required here is to store the engine tag in the couchdb metadata > >alongside > >the tgz. > > > > > >On Thu, Jul 25, 2013 at 6:38 PM, Benn Mapes > >wrote: > > > >> +1 to brett's comments. > >> Name - Human Readable name of the plugin to be used in the context > >>of > >> plugin > >> discovery. > >> ID - unique id used by tools to reference the plugin > >> Description - sentence+ about the plugin (optional?) > >> > >> As for how plugins should be loaded I liked Braden's suggestion that > >>plugin > >> authors decide what the default ref is for their plugin. Default > >>should > >>be > >> master if no ref is provided. > >> > >> > >> On Thu, Jul 25, 2013 at 1:27 PM, Steven Gill > >> > >> wrote: > >> > >> > I am going to hold off on testing + deploying+ merging this back > >>in > >>until > >> > we get some sort of consensus on naming > >> > > >> > > >> > On Thu, Jul 25, 2013 at 12:10 PM, RUDD, Brett > >> > >> wrote: > >> > > >> > > name is human readable and should be retained for plugin > >>discovery > >> tools > >> > > etc. (such as build.phonegap.com) > >> > > > >> > > in the wild, i find description is anything from a sentence to a > >>small > >> > > paragraph, so a smaller human readable field as a name is > >>valuable. > >> > > > >> > > as for using id instead of name for plugman, i transfer my > >>voting > >>power > >> > to > >>>
Re: Plugin / Platform mismatch problems
I'll try to summarize where we were before and where we are at currently. In The Beginning: - we spec'ed an `id` attribute to the plugin manifest under the pretense of having a unique identifier (generally a good idea), and a preemptive approach at easing a situation where we have a multi-registry universe (For example: BlackBerry, Apache, Google all hosting plugin registries) - the element was to be a human-readable, "pretty" label. It can have spaces, apostrophes, etc. just like the element in config.xml In The Present: - we are at the point where we are using an existing system (npm) that has different constraints on uniquely identifying a project. Npm uses a name, with no spaces, no underscores, and some other char constraints. - which leads us to our current conundrum: which field do we use to uniquely identify a plugin, and which solution should we employ to map between our plugin specification for naming / id'ing packages vs. Npm's. There are many different ways to solve this problem, each with varying degrees of difficulty to implement and each having a different answer to the question of "how much will we need to diverge from npm to support it": - using a plugin id as the npm "name" - using a plugin's "cleaned up" contents (no spaces or funny characters) as the npm name Finally, discovery is the last use case that needs to be addressed here. What is npm's current strategy and what do we want to support? On 7/26/13 11:21 AM, "Anis KADRI" wrote: >Exactly! Only the ones we need too! We're already doing this for >name/version/description so it would just be a few more. > >On Fri, Jul 26, 2013 at 11:19 AM, Filip Maj wrote: >> Ahh yeah. Some kind of at-publish-time conversion of certain plugin.xml >> fields to json fields? >> >> On 7/26/13 10:27 AM, "Anis KADRI" wrote: >> >>>I think XML is not a query friendly language. I suggest we add an >>>engine field initially and then add fields as we need them. I suspect >>>we won't be needing the bulk of plugin.xml in the registry. I have to >>>experiment with custom fields still but it seems possible. I will >>>report back sometime today. >>> >>>On Fri, Jul 26, 2013 at 9:23 AM, Filip Maj wrote: I think this was brought up before, but why not store the plugin xml in its entirety? I can us needing more bits down the road, such as dependencies and platform version requirements. On 7/26/13 7:32 AM, "Andrew Grieve" wrote: >That all sounds good, but let's talk more about the git ref part: > >It looks like our npm-based directory system is going to host the .tgz >of >the plugins, so it won't matter what git ref the .tgz maps back to >unless >we think that a lot of people are not going to use our directory >service. > >One thing that would be useful though, is a way to list plugins >compatible >with your version of cordova (e.g. query for the latest version of >cordova-plugin-file that is compatible with 3.0.0). I think all that's >required here is to store the engine tag in the couchdb metadata >alongside >the tgz. > > >On Thu, Jul 25, 2013 at 6:38 PM, Benn Mapes >wrote: > >> +1 to brett's comments. >> Name - Human Readable name of the plugin to be used in the context >>of >> plugin >> discovery. >> ID - unique id used by tools to reference the plugin >> Description - sentence+ about the plugin (optional?) >> >> As for how plugins should be loaded I liked Braden's suggestion that >>plugin >> authors decide what the default ref is for their plugin. Default >>should >>be >> master if no ref is provided. >> >> >> On Thu, Jul 25, 2013 at 1:27 PM, Steven Gill >> >> wrote: >> >> > I am going to hold off on testing + deploying+ merging this back >>in >>until >> > we get some sort of consensus on naming >> > >> > >> > On Thu, Jul 25, 2013 at 12:10 PM, RUDD, Brett >> >> wrote: >> > >> > > name is human readable and should be retained for plugin >>discovery >> tools >> > > etc. (such as build.phonegap.com) >> > > >> > > in the wild, i find description is anything from a sentence to a >>small >> > > paragraph, so a smaller human readable field as a name is >>valuable. >> > > >> > > as for using id instead of name for plugman, i transfer my >>voting >>power >> > to >> > > anis. >> > > >> > > -brett >> > > >> > > On 25 Jul 2013, at 11:59, Shazron wrote: >> > > >> > > > Maybe "name" is the "human" readable name as opposed to id >>which >>is >> for >> > > > tools >> > > > >> > > > >> > > > On Thu, Jul 25, 2013 at 11:45 AM, Andrew Grieve < >> agri...@chromium.org >> > > >wrote: >> > > > >> > > >> Anis - can we make it use id instead? I think that's more >>inline >> with >> > > the >> >
Re: Plugin / Platform mismatch problems
Exactly! Only the ones we need too! We're already doing this for name/version/description so it would just be a few more. On Fri, Jul 26, 2013 at 11:19 AM, Filip Maj wrote: > Ahh yeah. Some kind of at-publish-time conversion of certain plugin.xml > fields to json fields? > > On 7/26/13 10:27 AM, "Anis KADRI" wrote: > >>I think XML is not a query friendly language. I suggest we add an >>engine field initially and then add fields as we need them. I suspect >>we won't be needing the bulk of plugin.xml in the registry. I have to >>experiment with custom fields still but it seems possible. I will >>report back sometime today. >> >>On Fri, Jul 26, 2013 at 9:23 AM, Filip Maj wrote: >>> I think this was brought up before, but why not store the plugin xml in >>> its entirety? I can us needing more bits down the road, such as >>> dependencies and platform version requirements. >>> >>> >>> On 7/26/13 7:32 AM, "Andrew Grieve" wrote: >>> That all sounds good, but let's talk more about the git ref part: It looks like our npm-based directory system is going to host the .tgz of the plugins, so it won't matter what git ref the .tgz maps back to unless we think that a lot of people are not going to use our directory service. One thing that would be useful though, is a way to list plugins compatible with your version of cordova (e.g. query for the latest version of cordova-plugin-file that is compatible with 3.0.0). I think all that's required here is to store the engine tag in the couchdb metadata alongside the tgz. On Thu, Jul 25, 2013 at 6:38 PM, Benn Mapes wrote: > +1 to brett's comments. > Name - Human Readable name of the plugin to be used in the context of > plugin > discovery. > ID - unique id used by tools to reference the plugin > Description - sentence+ about the plugin (optional?) > > As for how plugins should be loaded I liked Braden's suggestion that >plugin > authors decide what the default ref is for their plugin. Default >should >be > master if no ref is provided. > > > On Thu, Jul 25, 2013 at 1:27 PM, Steven Gill > wrote: > > > I am going to hold off on testing + deploying+ merging this back in >until > > we get some sort of consensus on naming > > > > > > On Thu, Jul 25, 2013 at 12:10 PM, RUDD, Brett > wrote: > > > > > name is human readable and should be retained for plugin discovery > tools > > > etc. (such as build.phonegap.com) > > > > > > in the wild, i find description is anything from a sentence to a >small > > > paragraph, so a smaller human readable field as a name is >valuable. > > > > > > as for using id instead of name for plugman, i transfer my voting >power > > to > > > anis. > > > > > > -brett > > > > > > On 25 Jul 2013, at 11:59, Shazron wrote: > > > > > > > Maybe "name" is the "human" readable name as opposed to id which >is > for > > > > tools > > > > > > > > > > > > On Thu, Jul 25, 2013 at 11:45 AM, Andrew Grieve < > agri...@chromium.org > > > >wrote: > > > > > > > >> Anis - can we make it use id instead? I think that's more >inline > with > > > the > > > >> purpose of the field. > > > >> > > > >> Maybe we should remove the name field? I can't think of a >meaningful > > > >> distinction between name and id given that we already have a > > description > > > >> field. > > > >> > > > >> > > > >> On Thu, Jul 25, 2013 at 2:35 PM, Steven Gill < > stevengil...@gmail.com> > > > >> wrote: > > > >> > > > >>> Thanks for the advice Shaz and Andrew. > > > >>> > > > >>> I will make sure to mention the issue in the commit so the bot > picks > > it > > > >> up. > > > >>> > > > >>> Just talked to Anis and he says it is the name tag and not the >ID. > I > > > >> could > > > >>> go and rename all of the core plugins to start with 'core-' if >that > > > makes > > > >>> more sense to people. I like it. Distinguishes core plugins >from > > > >> community > > > >>> ones. > > > >>> > > > >>> I will make sure to do a release bug once ready. Mobile-spec >tests > > for > > > >> sure > > > >>> and I will upload to registry (gotta do it eventually :P) > > > >>> > > > >>> -Steve > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> On Thu, Jul 25, 2013 at 6:21 AM, Andrew Grieve < > agri...@chromium.org > > > > > > >>> wrote: > > > >>> > > > Steve - If you mention the CB- in the commit description >then > a > > > bot > > > will automatically add a comment to the issue with the commit > link. > > > The > > > issues aren't very useful if they don't point to the
Re: Plugin / Platform mismatch problems
Ahh yeah. Some kind of at-publish-time conversion of certain plugin.xml fields to json fields? On 7/26/13 10:27 AM, "Anis KADRI" wrote: >I think XML is not a query friendly language. I suggest we add an >engine field initially and then add fields as we need them. I suspect >we won't be needing the bulk of plugin.xml in the registry. I have to >experiment with custom fields still but it seems possible. I will >report back sometime today. > >On Fri, Jul 26, 2013 at 9:23 AM, Filip Maj wrote: >> I think this was brought up before, but why not store the plugin xml in >> its entirety? I can us needing more bits down the road, such as >> dependencies and platform version requirements. >> >> >> On 7/26/13 7:32 AM, "Andrew Grieve" wrote: >> >>>That all sounds good, but let's talk more about the git ref part: >>> >>>It looks like our npm-based directory system is going to host the .tgz >>>of >>>the plugins, so it won't matter what git ref the .tgz maps back to >>>unless >>>we think that a lot of people are not going to use our directory >>>service. >>> >>>One thing that would be useful though, is a way to list plugins >>>compatible >>>with your version of cordova (e.g. query for the latest version of >>>cordova-plugin-file that is compatible with 3.0.0). I think all that's >>>required here is to store the engine tag in the couchdb metadata >>>alongside >>>the tgz. >>> >>> >>>On Thu, Jul 25, 2013 at 6:38 PM, Benn Mapes >>>wrote: >>> +1 to brett's comments. Name - Human Readable name of the plugin to be used in the context of plugin discovery. ID - unique id used by tools to reference the plugin Description - sentence+ about the plugin (optional?) As for how plugins should be loaded I liked Braden's suggestion that plugin authors decide what the default ref is for their plugin. Default should be master if no ref is provided. On Thu, Jul 25, 2013 at 1:27 PM, Steven Gill wrote: > I am going to hold off on testing + deploying+ merging this back in until > we get some sort of consensus on naming > > > On Thu, Jul 25, 2013 at 12:10 PM, RUDD, Brett wrote: > > > name is human readable and should be retained for plugin discovery tools > > etc. (such as build.phonegap.com) > > > > in the wild, i find description is anything from a sentence to a small > > paragraph, so a smaller human readable field as a name is valuable. > > > > as for using id instead of name for plugman, i transfer my voting power > to > > anis. > > > > -brett > > > > On 25 Jul 2013, at 11:59, Shazron wrote: > > > > > Maybe "name" is the "human" readable name as opposed to id which is for > > > tools > > > > > > > > > On Thu, Jul 25, 2013 at 11:45 AM, Andrew Grieve < agri...@chromium.org > > >wrote: > > > > > >> Anis - can we make it use id instead? I think that's more inline with > > the > > >> purpose of the field. > > >> > > >> Maybe we should remove the name field? I can't think of a meaningful > > >> distinction between name and id given that we already have a > description > > >> field. > > >> > > >> > > >> On Thu, Jul 25, 2013 at 2:35 PM, Steven Gill < stevengil...@gmail.com> > > >> wrote: > > >> > > >>> Thanks for the advice Shaz and Andrew. > > >>> > > >>> I will make sure to mention the issue in the commit so the bot picks > it > > >> up. > > >>> > > >>> Just talked to Anis and he says it is the name tag and not the ID. I > > >> could > > >>> go and rename all of the core plugins to start with 'core-' if that > > makes > > >>> more sense to people. I like it. Distinguishes core plugins from > > >> community > > >>> ones. > > >>> > > >>> I will make sure to do a release bug once ready. Mobile-spec tests > for > > >> sure > > >>> and I will upload to registry (gotta do it eventually :P) > > >>> > > >>> -Steve > > >>> > > >>> > > >>> > > >>> > > >>> On Thu, Jul 25, 2013 at 6:21 AM, Andrew Grieve < agri...@chromium.org > > > > >>> wrote: > > >>> > > Steve - If you mention the CB- in the commit description then a > > bot > > will automatically add a comment to the issue with the commit link. > > The > > issues aren't very useful if they don't point to the commits that > fix > > >>> them. > > > > For the names - just wanted to verify whether it was the name field > or > > >>> the > > id field that can't have caps/spaces? If it's the name, then ID > seems > > a > > >>> bit > > redundant. Either w
Re: Plugin / Platform mismatch problems
Yeah we can use id and keep name around for human readable purpose. I am fine with it. I just think that typing giant package names is just not user friendly from a developer's perspective. Maybe it's just me. On Thu, Jul 25, 2013 at 1:27 PM, Steven Gill wrote: > I am going to hold off on testing + deploying+ merging this back in until > we get some sort of consensus on naming > > > On Thu, Jul 25, 2013 at 12:10 PM, RUDD, Brett wrote: > >> name is human readable and should be retained for plugin discovery tools >> etc. (such as build.phonegap.com) >> >> in the wild, i find description is anything from a sentence to a small >> paragraph, so a smaller human readable field as a name is valuable. >> >> as for using id instead of name for plugman, i transfer my voting power to >> anis. >> >> -brett >> >> On 25 Jul 2013, at 11:59, Shazron wrote: >> >> > Maybe "name" is the "human" readable name as opposed to id which is for >> > tools >> > >> > >> > On Thu, Jul 25, 2013 at 11:45 AM, Andrew Grieve > >wrote: >> > >> >> Anis - can we make it use id instead? I think that's more inline with >> the >> >> purpose of the field. >> >> >> >> Maybe we should remove the name field? I can't think of a meaningful >> >> distinction between name and id given that we already have a description >> >> field. >> >> >> >> >> >> On Thu, Jul 25, 2013 at 2:35 PM, Steven Gill >> >> wrote: >> >> >> >>> Thanks for the advice Shaz and Andrew. >> >>> >> >>> I will make sure to mention the issue in the commit so the bot picks it >> >> up. >> >>> >> >>> Just talked to Anis and he says it is the name tag and not the ID. I >> >> could >> >>> go and rename all of the core plugins to start with 'core-' if that >> makes >> >>> more sense to people. I like it. Distinguishes core plugins from >> >> community >> >>> ones. >> >>> >> >>> I will make sure to do a release bug once ready. Mobile-spec tests for >> >> sure >> >>> and I will upload to registry (gotta do it eventually :P) >> >>> >> >>> -Steve >> >>> >> >>> >> >>> >> >>> >> >>> On Thu, Jul 25, 2013 at 6:21 AM, Andrew Grieve >> >>> wrote: >> >>> >> Steve - If you mention the CB- in the commit description then a >> bot >> will automatically add a comment to the issue with the commit link. >> The >> issues aren't very useful if they don't point to the commits that fix >> >>> them. >> >> For the names - just wanted to verify whether it was the name field or >> >>> the >> id field that can't have caps/spaces? If it's the name, then ID seems >> a >> >>> bit >> redundant. Either way - I think it's important to have some sort of >> >>> common >> prefix for cordova-core plugins. E.g. core-vibration, or >> org.apache.cordova.vibration. >> >> I think any merge into master is worthy of a release bug. That way you >> >>> can >> link it with the commit that bumps the package.json version. Probably >> >> one >> bug for all the plugins being released is fine though. In the release >> >>> bug, >> I think you should state what you tested, mobile-spec is the goto, but >> >> in >> this case, you may want to say that you tested uploading to the >> plugins >> registry. >> >> >> On Wed, Jul 24, 2013 at 6:26 PM, Shazron wrote: >> >> > plugin.xml changes only correct? IMO bump the version and run the >> >> steps >> > here to test plugin add: >> >>> http://wiki.apache.org/cordova/WorkingWithThree >> > >> > >> > >> > >> > On Wed, Jul 24, 2013 at 3:03 PM, Steven Gill > >>> >> > wrote: >> > >> >> So I just added a dev branch for all of the plugins and finished >> >> the >> > issues >> >> [1] [2] [3]. All three of these were minor fixes and I don't >> >> believe >> >> require retesting all of the plugins on every platform. What should >> >>> my >> > next >> >> steps be? I know if I merge into master, I should bump the version >> >>> for >> > all >> >> of them to 0.1.1. Is this something I should create a release bug >> >> for >> and >> >> get tested before merging into master? >> >> >> >> >> >> [1] https://issues.apache.org/jira/browse/CB-4371 >> >> [2] https://issues.apache.org/jira/browse/CB-4370 >> >> [3] https://issues.apache.org/jira/browse/CB-4338 >> >> >> >> >> >> On Mon, Jul 22, 2013 at 12:41 PM, Brian LeRoux wrote: >> >> >> >>> Like that >> >>> >> >>> On Mon, Jul 22, 2013 at 3:33 PM, Andrew Grieve < >> >>> agri...@chromium.org >> > >> >>> wrote: >> Oh! Oh! Perhaps have multiple definitions based on CDV version. >> e.g.: >> >> >> refs/head/2.8.x >> >> >> refs/tags/stable >> >> >> >> Then, when someone plugman installs the git URL, it can fetch >> >> it >> and >> checkout a version that best matches your cordova version. >> Then, when you updat
Re: Plugin / Platform mismatch problems
I think XML is not a query friendly language. I suggest we add an engine field initially and then add fields as we need them. I suspect we won't be needing the bulk of plugin.xml in the registry. I have to experiment with custom fields still but it seems possible. I will report back sometime today. On Fri, Jul 26, 2013 at 9:23 AM, Filip Maj wrote: > I think this was brought up before, but why not store the plugin xml in > its entirety? I can us needing more bits down the road, such as > dependencies and platform version requirements. > > > On 7/26/13 7:32 AM, "Andrew Grieve" wrote: > >>That all sounds good, but let's talk more about the git ref part: >> >>It looks like our npm-based directory system is going to host the .tgz of >>the plugins, so it won't matter what git ref the .tgz maps back to unless >>we think that a lot of people are not going to use our directory service. >> >>One thing that would be useful though, is a way to list plugins compatible >>with your version of cordova (e.g. query for the latest version of >>cordova-plugin-file that is compatible with 3.0.0). I think all that's >>required here is to store the engine tag in the couchdb metadata alongside >>the tgz. >> >> >>On Thu, Jul 25, 2013 at 6:38 PM, Benn Mapes wrote: >> >>> +1 to brett's comments. >>> Name - Human Readable name of the plugin to be used in the context of >>> plugin >>> discovery. >>> ID - unique id used by tools to reference the plugin >>> Description - sentence+ about the plugin (optional?) >>> >>> As for how plugins should be loaded I liked Braden's suggestion that >>>plugin >>> authors decide what the default ref is for their plugin. Default should >>>be >>> master if no ref is provided. >>> >>> >>> On Thu, Jul 25, 2013 at 1:27 PM, Steven Gill >>> wrote: >>> >>> > I am going to hold off on testing + deploying+ merging this back in >>>until >>> > we get some sort of consensus on naming >>> > >>> > >>> > On Thu, Jul 25, 2013 at 12:10 PM, RUDD, Brett >>> wrote: >>> > >>> > > name is human readable and should be retained for plugin discovery >>> tools >>> > > etc. (such as build.phonegap.com) >>> > > >>> > > in the wild, i find description is anything from a sentence to a >>>small >>> > > paragraph, so a smaller human readable field as a name is valuable. >>> > > >>> > > as for using id instead of name for plugman, i transfer my voting >>>power >>> > to >>> > > anis. >>> > > >>> > > -brett >>> > > >>> > > On 25 Jul 2013, at 11:59, Shazron wrote: >>> > > >>> > > > Maybe "name" is the "human" readable name as opposed to id which >>>is >>> for >>> > > > tools >>> > > > >>> > > > >>> > > > On Thu, Jul 25, 2013 at 11:45 AM, Andrew Grieve < >>> agri...@chromium.org >>> > > >wrote: >>> > > > >>> > > >> Anis - can we make it use id instead? I think that's more inline >>> with >>> > > the >>> > > >> purpose of the field. >>> > > >> >>> > > >> Maybe we should remove the name field? I can't think of a >>>meaningful >>> > > >> distinction between name and id given that we already have a >>> > description >>> > > >> field. >>> > > >> >>> > > >> >>> > > >> On Thu, Jul 25, 2013 at 2:35 PM, Steven Gill < >>> stevengil...@gmail.com> >>> > > >> wrote: >>> > > >> >>> > > >>> Thanks for the advice Shaz and Andrew. >>> > > >>> >>> > > >>> I will make sure to mention the issue in the commit so the bot >>> picks >>> > it >>> > > >> up. >>> > > >>> >>> > > >>> Just talked to Anis and he says it is the name tag and not the >>>ID. >>> I >>> > > >> could >>> > > >>> go and rename all of the core plugins to start with 'core-' if >>>that >>> > > makes >>> > > >>> more sense to people. I like it. Distinguishes core plugins from >>> > > >> community >>> > > >>> ones. >>> > > >>> >>> > > >>> I will make sure to do a release bug once ready. Mobile-spec >>>tests >>> > for >>> > > >> sure >>> > > >>> and I will upload to registry (gotta do it eventually :P) >>> > > >>> >>> > > >>> -Steve >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> On Thu, Jul 25, 2013 at 6:21 AM, Andrew Grieve < >>> agri...@chromium.org >>> > > >>> > > >>> wrote: >>> > > >>> >>> > > Steve - If you mention the CB- in the commit description >>>then >>> a >>> > > bot >>> > > will automatically add a comment to the issue with the commit >>> link. >>> > > The >>> > > issues aren't very useful if they don't point to the commits >>>that >>> > fix >>> > > >>> them. >>> > > >>> > > For the names - just wanted to verify whether it was the name >>> field >>> > or >>> > > >>> the >>> > > id field that can't have caps/spaces? If it's the name, then ID >>> > seems >>> > > a >>> > > >>> bit >>> > > redundant. Either way - I think it's important to have some >>>sort >>> of >>> > > >>> common >>> > > prefix for cordova-core plugins. E.g. core-vibration, or >>> > > org.apache.cordova.vibration. >>> > > >>> > > I think any merge into master is worthy of a release bug. That >>>way >>> > you >>> > > >>> can >>> > > link i
Re: Plugin / Platform mismatch problems
I think this was brought up before, but why not store the plugin xml in its entirety? I can us needing more bits down the road, such as dependencies and platform version requirements. On 7/26/13 7:32 AM, "Andrew Grieve" wrote: >That all sounds good, but let's talk more about the git ref part: > >It looks like our npm-based directory system is going to host the .tgz of >the plugins, so it won't matter what git ref the .tgz maps back to unless >we think that a lot of people are not going to use our directory service. > >One thing that would be useful though, is a way to list plugins compatible >with your version of cordova (e.g. query for the latest version of >cordova-plugin-file that is compatible with 3.0.0). I think all that's >required here is to store the engine tag in the couchdb metadata alongside >the tgz. > > >On Thu, Jul 25, 2013 at 6:38 PM, Benn Mapes wrote: > >> +1 to brett's comments. >> Name - Human Readable name of the plugin to be used in the context of >> plugin >> discovery. >> ID - unique id used by tools to reference the plugin >> Description - sentence+ about the plugin (optional?) >> >> As for how plugins should be loaded I liked Braden's suggestion that >>plugin >> authors decide what the default ref is for their plugin. Default should >>be >> master if no ref is provided. >> >> >> On Thu, Jul 25, 2013 at 1:27 PM, Steven Gill >> wrote: >> >> > I am going to hold off on testing + deploying+ merging this back in >>until >> > we get some sort of consensus on naming >> > >> > >> > On Thu, Jul 25, 2013 at 12:10 PM, RUDD, Brett >> wrote: >> > >> > > name is human readable and should be retained for plugin discovery >> tools >> > > etc. (such as build.phonegap.com) >> > > >> > > in the wild, i find description is anything from a sentence to a >>small >> > > paragraph, so a smaller human readable field as a name is valuable. >> > > >> > > as for using id instead of name for plugman, i transfer my voting >>power >> > to >> > > anis. >> > > >> > > -brett >> > > >> > > On 25 Jul 2013, at 11:59, Shazron wrote: >> > > >> > > > Maybe "name" is the "human" readable name as opposed to id which >>is >> for >> > > > tools >> > > > >> > > > >> > > > On Thu, Jul 25, 2013 at 11:45 AM, Andrew Grieve < >> agri...@chromium.org >> > > >wrote: >> > > > >> > > >> Anis - can we make it use id instead? I think that's more inline >> with >> > > the >> > > >> purpose of the field. >> > > >> >> > > >> Maybe we should remove the name field? I can't think of a >>meaningful >> > > >> distinction between name and id given that we already have a >> > description >> > > >> field. >> > > >> >> > > >> >> > > >> On Thu, Jul 25, 2013 at 2:35 PM, Steven Gill < >> stevengil...@gmail.com> >> > > >> wrote: >> > > >> >> > > >>> Thanks for the advice Shaz and Andrew. >> > > >>> >> > > >>> I will make sure to mention the issue in the commit so the bot >> picks >> > it >> > > >> up. >> > > >>> >> > > >>> Just talked to Anis and he says it is the name tag and not the >>ID. >> I >> > > >> could >> > > >>> go and rename all of the core plugins to start with 'core-' if >>that >> > > makes >> > > >>> more sense to people. I like it. Distinguishes core plugins from >> > > >> community >> > > >>> ones. >> > > >>> >> > > >>> I will make sure to do a release bug once ready. Mobile-spec >>tests >> > for >> > > >> sure >> > > >>> and I will upload to registry (gotta do it eventually :P) >> > > >>> >> > > >>> -Steve >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> On Thu, Jul 25, 2013 at 6:21 AM, Andrew Grieve < >> agri...@chromium.org >> > > >> > > >>> wrote: >> > > >>> >> > > Steve - If you mention the CB- in the commit description >>then >> a >> > > bot >> > > will automatically add a comment to the issue with the commit >> link. >> > > The >> > > issues aren't very useful if they don't point to the commits >>that >> > fix >> > > >>> them. >> > > >> > > For the names - just wanted to verify whether it was the name >> field >> > or >> > > >>> the >> > > id field that can't have caps/spaces? If it's the name, then ID >> > seems >> > > a >> > > >>> bit >> > > redundant. Either way - I think it's important to have some >>sort >> of >> > > >>> common >> > > prefix for cordova-core plugins. E.g. core-vibration, or >> > > org.apache.cordova.vibration. >> > > >> > > I think any merge into master is worthy of a release bug. That >>way >> > you >> > > >>> can >> > > link it with the commit that bumps the package.json version. >> > Probably >> > > >> one >> > > bug for all the plugins being released is fine though. In the >> > release >> > > >>> bug, >> > > I think you should state what you tested, mobile-spec is the >>goto, >> > but >> > > >> in >> > > this case, you may want to say that you tested uploading to the >> > > plugins >> > > registry. >> > > >> > > >> > > On Wed, Jul 24, 2013 at 6:26 PM, Shazron >> wrote: >> > > >> > > >>>
Re: Plugin / Platform mismatch problems
That all sounds good, but let's talk more about the git ref part: It looks like our npm-based directory system is going to host the .tgz of the plugins, so it won't matter what git ref the .tgz maps back to unless we think that a lot of people are not going to use our directory service. One thing that would be useful though, is a way to list plugins compatible with your version of cordova (e.g. query for the latest version of cordova-plugin-file that is compatible with 3.0.0). I think all that's required here is to store the engine tag in the couchdb metadata alongside the tgz. On Thu, Jul 25, 2013 at 6:38 PM, Benn Mapes wrote: > +1 to brett's comments. > Name - Human Readable name of the plugin to be used in the context of > plugin > discovery. > ID - unique id used by tools to reference the plugin > Description - sentence+ about the plugin (optional?) > > As for how plugins should be loaded I liked Braden's suggestion that plugin > authors decide what the default ref is for their plugin. Default should be > master if no ref is provided. > > > On Thu, Jul 25, 2013 at 1:27 PM, Steven Gill > wrote: > > > I am going to hold off on testing + deploying+ merging this back in until > > we get some sort of consensus on naming > > > > > > On Thu, Jul 25, 2013 at 12:10 PM, RUDD, Brett > wrote: > > > > > name is human readable and should be retained for plugin discovery > tools > > > etc. (such as build.phonegap.com) > > > > > > in the wild, i find description is anything from a sentence to a small > > > paragraph, so a smaller human readable field as a name is valuable. > > > > > > as for using id instead of name for plugman, i transfer my voting power > > to > > > anis. > > > > > > -brett > > > > > > On 25 Jul 2013, at 11:59, Shazron wrote: > > > > > > > Maybe "name" is the "human" readable name as opposed to id which is > for > > > > tools > > > > > > > > > > > > On Thu, Jul 25, 2013 at 11:45 AM, Andrew Grieve < > agri...@chromium.org > > > >wrote: > > > > > > > >> Anis - can we make it use id instead? I think that's more inline > with > > > the > > > >> purpose of the field. > > > >> > > > >> Maybe we should remove the name field? I can't think of a meaningful > > > >> distinction between name and id given that we already have a > > description > > > >> field. > > > >> > > > >> > > > >> On Thu, Jul 25, 2013 at 2:35 PM, Steven Gill < > stevengil...@gmail.com> > > > >> wrote: > > > >> > > > >>> Thanks for the advice Shaz and Andrew. > > > >>> > > > >>> I will make sure to mention the issue in the commit so the bot > picks > > it > > > >> up. > > > >>> > > > >>> Just talked to Anis and he says it is the name tag and not the ID. > I > > > >> could > > > >>> go and rename all of the core plugins to start with 'core-' if that > > > makes > > > >>> more sense to people. I like it. Distinguishes core plugins from > > > >> community > > > >>> ones. > > > >>> > > > >>> I will make sure to do a release bug once ready. Mobile-spec tests > > for > > > >> sure > > > >>> and I will upload to registry (gotta do it eventually :P) > > > >>> > > > >>> -Steve > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> On Thu, Jul 25, 2013 at 6:21 AM, Andrew Grieve < > agri...@chromium.org > > > > > > >>> wrote: > > > >>> > > > Steve - If you mention the CB- in the commit description then > a > > > bot > > > will automatically add a comment to the issue with the commit > link. > > > The > > > issues aren't very useful if they don't point to the commits that > > fix > > > >>> them. > > > > > > For the names - just wanted to verify whether it was the name > field > > or > > > >>> the > > > id field that can't have caps/spaces? If it's the name, then ID > > seems > > > a > > > >>> bit > > > redundant. Either way - I think it's important to have some sort > of > > > >>> common > > > prefix for cordova-core plugins. E.g. core-vibration, or > > > org.apache.cordova.vibration. > > > > > > I think any merge into master is worthy of a release bug. That way > > you > > > >>> can > > > link it with the commit that bumps the package.json version. > > Probably > > > >> one > > > bug for all the plugins being released is fine though. In the > > release > > > >>> bug, > > > I think you should state what you tested, mobile-spec is the goto, > > but > > > >> in > > > this case, you may want to say that you tested uploading to the > > > plugins > > > registry. > > > > > > > > > On Wed, Jul 24, 2013 at 6:26 PM, Shazron > wrote: > > > > > > > plugin.xml changes only correct? IMO bump the version and run the > > > >> steps > > > > here to test plugin add: > > > >>> http://wiki.apache.org/cordova/WorkingWithThree > > > > > > > > > > > > > > > > > > > > On Wed, Jul 24, 2013 at 3:03 PM, Steven Gill < > > stevengil...@gmail.com > > > >>> > > > > wrote: > > > > > > > >> So I just added a dev branch for all of the pl
Re: Plugin / Platform mismatch problems
+1 to brett's comments. Name - Human Readable name of the plugin to be used in the context of plugin discovery. ID - unique id used by tools to reference the plugin Description - sentence+ about the plugin (optional?) As for how plugins should be loaded I liked Braden's suggestion that plugin authors decide what the default ref is for their plugin. Default should be master if no ref is provided. On Thu, Jul 25, 2013 at 1:27 PM, Steven Gill wrote: > I am going to hold off on testing + deploying+ merging this back in until > we get some sort of consensus on naming > > > On Thu, Jul 25, 2013 at 12:10 PM, RUDD, Brett wrote: > > > name is human readable and should be retained for plugin discovery tools > > etc. (such as build.phonegap.com) > > > > in the wild, i find description is anything from a sentence to a small > > paragraph, so a smaller human readable field as a name is valuable. > > > > as for using id instead of name for plugman, i transfer my voting power > to > > anis. > > > > -brett > > > > On 25 Jul 2013, at 11:59, Shazron wrote: > > > > > Maybe "name" is the "human" readable name as opposed to id which is for > > > tools > > > > > > > > > On Thu, Jul 25, 2013 at 11:45 AM, Andrew Grieve > >wrote: > > > > > >> Anis - can we make it use id instead? I think that's more inline with > > the > > >> purpose of the field. > > >> > > >> Maybe we should remove the name field? I can't think of a meaningful > > >> distinction between name and id given that we already have a > description > > >> field. > > >> > > >> > > >> On Thu, Jul 25, 2013 at 2:35 PM, Steven Gill > > >> wrote: > > >> > > >>> Thanks for the advice Shaz and Andrew. > > >>> > > >>> I will make sure to mention the issue in the commit so the bot picks > it > > >> up. > > >>> > > >>> Just talked to Anis and he says it is the name tag and not the ID. I > > >> could > > >>> go and rename all of the core plugins to start with 'core-' if that > > makes > > >>> more sense to people. I like it. Distinguishes core plugins from > > >> community > > >>> ones. > > >>> > > >>> I will make sure to do a release bug once ready. Mobile-spec tests > for > > >> sure > > >>> and I will upload to registry (gotta do it eventually :P) > > >>> > > >>> -Steve > > >>> > > >>> > > >>> > > >>> > > >>> On Thu, Jul 25, 2013 at 6:21 AM, Andrew Grieve > > > >>> wrote: > > >>> > > Steve - If you mention the CB- in the commit description then a > > bot > > will automatically add a comment to the issue with the commit link. > > The > > issues aren't very useful if they don't point to the commits that > fix > > >>> them. > > > > For the names - just wanted to verify whether it was the name field > or > > >>> the > > id field that can't have caps/spaces? If it's the name, then ID > seems > > a > > >>> bit > > redundant. Either way - I think it's important to have some sort of > > >>> common > > prefix for cordova-core plugins. E.g. core-vibration, or > > org.apache.cordova.vibration. > > > > I think any merge into master is worthy of a release bug. That way > you > > >>> can > > link it with the commit that bumps the package.json version. > Probably > > >> one > > bug for all the plugins being released is fine though. In the > release > > >>> bug, > > I think you should state what you tested, mobile-spec is the goto, > but > > >> in > > this case, you may want to say that you tested uploading to the > > plugins > > registry. > > > > > > On Wed, Jul 24, 2013 at 6:26 PM, Shazron wrote: > > > > > plugin.xml changes only correct? IMO bump the version and run the > > >> steps > > > here to test plugin add: > > >>> http://wiki.apache.org/cordova/WorkingWithThree > > > > > > > > > > > > > > > On Wed, Jul 24, 2013 at 3:03 PM, Steven Gill < > stevengil...@gmail.com > > >>> > > > wrote: > > > > > >> So I just added a dev branch for all of the plugins and finished > > >> the > > > issues > > >> [1] [2] [3]. All three of these were minor fixes and I don't > > >> believe > > >> require retesting all of the plugins on every platform. What > should > > >>> my > > > next > > >> steps be? I know if I merge into master, I should bump the version > > >>> for > > > all > > >> of them to 0.1.1. Is this something I should create a release bug > > >> for > > and > > >> get tested before merging into master? > > >> > > >> > > >> [1] https://issues.apache.org/jira/browse/CB-4371 > > >> [2] https://issues.apache.org/jira/browse/CB-4370 > > >> [3] https://issues.apache.org/jira/browse/CB-4338 > > >> > > >> > > >> On Mon, Jul 22, 2013 at 12:41 PM, Brian LeRoux > wrote: > > >> > > >>> Like that > > >>> > > >>> On Mon, Jul 22, 2013 at 3:33 PM, Andrew Grieve < > > >>> agri...@chromium.org > > > > > >>> wrote: > > Oh! Oh! Perhaps have multiple definitions b
Re: Plugin / Platform mismatch problems
I am going to hold off on testing + deploying+ merging this back in until we get some sort of consensus on naming On Thu, Jul 25, 2013 at 12:10 PM, RUDD, Brett wrote: > name is human readable and should be retained for plugin discovery tools > etc. (such as build.phonegap.com) > > in the wild, i find description is anything from a sentence to a small > paragraph, so a smaller human readable field as a name is valuable. > > as for using id instead of name for plugman, i transfer my voting power to > anis. > > -brett > > On 25 Jul 2013, at 11:59, Shazron wrote: > > > Maybe "name" is the "human" readable name as opposed to id which is for > > tools > > > > > > On Thu, Jul 25, 2013 at 11:45 AM, Andrew Grieve >wrote: > > > >> Anis - can we make it use id instead? I think that's more inline with > the > >> purpose of the field. > >> > >> Maybe we should remove the name field? I can't think of a meaningful > >> distinction between name and id given that we already have a description > >> field. > >> > >> > >> On Thu, Jul 25, 2013 at 2:35 PM, Steven Gill > >> wrote: > >> > >>> Thanks for the advice Shaz and Andrew. > >>> > >>> I will make sure to mention the issue in the commit so the bot picks it > >> up. > >>> > >>> Just talked to Anis and he says it is the name tag and not the ID. I > >> could > >>> go and rename all of the core plugins to start with 'core-' if that > makes > >>> more sense to people. I like it. Distinguishes core plugins from > >> community > >>> ones. > >>> > >>> I will make sure to do a release bug once ready. Mobile-spec tests for > >> sure > >>> and I will upload to registry (gotta do it eventually :P) > >>> > >>> -Steve > >>> > >>> > >>> > >>> > >>> On Thu, Jul 25, 2013 at 6:21 AM, Andrew Grieve > >>> wrote: > >>> > Steve - If you mention the CB- in the commit description then a > bot > will automatically add a comment to the issue with the commit link. > The > issues aren't very useful if they don't point to the commits that fix > >>> them. > > For the names - just wanted to verify whether it was the name field or > >>> the > id field that can't have caps/spaces? If it's the name, then ID seems > a > >>> bit > redundant. Either way - I think it's important to have some sort of > >>> common > prefix for cordova-core plugins. E.g. core-vibration, or > org.apache.cordova.vibration. > > I think any merge into master is worthy of a release bug. That way you > >>> can > link it with the commit that bumps the package.json version. Probably > >> one > bug for all the plugins being released is fine though. In the release > >>> bug, > I think you should state what you tested, mobile-spec is the goto, but > >> in > this case, you may want to say that you tested uploading to the > plugins > registry. > > > On Wed, Jul 24, 2013 at 6:26 PM, Shazron wrote: > > > plugin.xml changes only correct? IMO bump the version and run the > >> steps > > here to test plugin add: > >>> http://wiki.apache.org/cordova/WorkingWithThree > > > > > > > > > > On Wed, Jul 24, 2013 at 3:03 PM, Steven Gill >>> > > wrote: > > > >> So I just added a dev branch for all of the plugins and finished > >> the > > issues > >> [1] [2] [3]. All three of these were minor fixes and I don't > >> believe > >> require retesting all of the plugins on every platform. What should > >>> my > > next > >> steps be? I know if I merge into master, I should bump the version > >>> for > > all > >> of them to 0.1.1. Is this something I should create a release bug > >> for > and > >> get tested before merging into master? > >> > >> > >> [1] https://issues.apache.org/jira/browse/CB-4371 > >> [2] https://issues.apache.org/jira/browse/CB-4370 > >> [3] https://issues.apache.org/jira/browse/CB-4338 > >> > >> > >> On Mon, Jul 22, 2013 at 12:41 PM, Brian LeRoux wrote: > >> > >>> Like that > >>> > >>> On Mon, Jul 22, 2013 at 3:33 PM, Andrew Grieve < > >>> agri...@chromium.org > > > >>> wrote: > Oh! Oh! Perhaps have multiple definitions based on CDV version. > e.g.: > > > refs/head/2.8.x > > > refs/tags/stable > > > > Then, when someone plugman installs the git URL, it can fetch > >> it > and > checkout a version that best matches your cordova version. > Then, when you update your cordova version, it can go through > >>> your > >>> plugins > and update them to different branches (unless you glue them to > >> a > ref > >> as a > part of your install URL) > > > > On Mon, Jul 22, 2013 at 2:44 PM, Braden Shepherdson < > >> bra...@chromium.org > wrote: > > > The model I had always imagined was tha
Re: Plugin / Platform mismatch problems
name is human readable and should be retained for plugin discovery tools etc. (such as build.phonegap.com) in the wild, i find description is anything from a sentence to a small paragraph, so a smaller human readable field as a name is valuable. as for using id instead of name for plugman, i transfer my voting power to anis. -brett On 25 Jul 2013, at 11:59, Shazron wrote: > Maybe "name" is the "human" readable name as opposed to id which is for > tools > > > On Thu, Jul 25, 2013 at 11:45 AM, Andrew Grieve wrote: > >> Anis - can we make it use id instead? I think that's more inline with the >> purpose of the field. >> >> Maybe we should remove the name field? I can't think of a meaningful >> distinction between name and id given that we already have a description >> field. >> >> >> On Thu, Jul 25, 2013 at 2:35 PM, Steven Gill >> wrote: >> >>> Thanks for the advice Shaz and Andrew. >>> >>> I will make sure to mention the issue in the commit so the bot picks it >> up. >>> >>> Just talked to Anis and he says it is the name tag and not the ID. I >> could >>> go and rename all of the core plugins to start with 'core-' if that makes >>> more sense to people. I like it. Distinguishes core plugins from >> community >>> ones. >>> >>> I will make sure to do a release bug once ready. Mobile-spec tests for >> sure >>> and I will upload to registry (gotta do it eventually :P) >>> >>> -Steve >>> >>> >>> >>> >>> On Thu, Jul 25, 2013 at 6:21 AM, Andrew Grieve >>> wrote: >>> Steve - If you mention the CB- in the commit description then a bot will automatically add a comment to the issue with the commit link. The issues aren't very useful if they don't point to the commits that fix >>> them. For the names - just wanted to verify whether it was the name field or >>> the id field that can't have caps/spaces? If it's the name, then ID seems a >>> bit redundant. Either way - I think it's important to have some sort of >>> common prefix for cordova-core plugins. E.g. core-vibration, or org.apache.cordova.vibration. I think any merge into master is worthy of a release bug. That way you >>> can link it with the commit that bumps the package.json version. Probably >> one bug for all the plugins being released is fine though. In the release >>> bug, I think you should state what you tested, mobile-spec is the goto, but >> in this case, you may want to say that you tested uploading to the plugins registry. On Wed, Jul 24, 2013 at 6:26 PM, Shazron wrote: > plugin.xml changes only correct? IMO bump the version and run the >> steps > here to test plugin add: >>> http://wiki.apache.org/cordova/WorkingWithThree > > > > > On Wed, Jul 24, 2013 at 3:03 PM, Steven Gill >> > wrote: > >> So I just added a dev branch for all of the plugins and finished >> the > issues >> [1] [2] [3]. All three of these were minor fixes and I don't >> believe >> require retesting all of the plugins on every platform. What should >>> my > next >> steps be? I know if I merge into master, I should bump the version >>> for > all >> of them to 0.1.1. Is this something I should create a release bug >> for and >> get tested before merging into master? >> >> >> [1] https://issues.apache.org/jira/browse/CB-4371 >> [2] https://issues.apache.org/jira/browse/CB-4370 >> [3] https://issues.apache.org/jira/browse/CB-4338 >> >> >> On Mon, Jul 22, 2013 at 12:41 PM, Brian LeRoux wrote: >> >>> Like that >>> >>> On Mon, Jul 22, 2013 at 3:33 PM, Andrew Grieve < >>> agri...@chromium.org > >>> wrote: Oh! Oh! Perhaps have multiple definitions based on CDV version. e.g.: refs/head/2.8.x refs/tags/stable Then, when someone plugman installs the git URL, it can fetch >> it and checkout a version that best matches your cordova version. Then, when you update your cordova version, it can go through >>> your >>> plugins and update them to different branches (unless you glue them to >> a ref >> as a part of your install URL) On Mon, Jul 22, 2013 at 2:44 PM, Braden Shepherdson < >> bra...@chromium.org wrote: > The model I had always imagined was that we would do something > similar >>> to > npm: Plugin authors decide what the default ref is for their plugin. >>> Could > be master, some other branch, a tag, a hash. That's what the > discovery >>> tool > will return when a user asks to add that plugin without >>> explicitly > specifying a version. I think this is a good idea we should > implement >>> too. > >
Re: Plugin / Platform mismatch problems
Maybe "name" is the "human" readable name as opposed to id which is for tools On Thu, Jul 25, 2013 at 11:45 AM, Andrew Grieve wrote: > Anis - can we make it use id instead? I think that's more inline with the > purpose of the field. > > Maybe we should remove the name field? I can't think of a meaningful > distinction between name and id given that we already have a description > field. > > > On Thu, Jul 25, 2013 at 2:35 PM, Steven Gill > wrote: > > > Thanks for the advice Shaz and Andrew. > > > > I will make sure to mention the issue in the commit so the bot picks it > up. > > > > Just talked to Anis and he says it is the name tag and not the ID. I > could > > go and rename all of the core plugins to start with 'core-' if that makes > > more sense to people. I like it. Distinguishes core plugins from > community > > ones. > > > > I will make sure to do a release bug once ready. Mobile-spec tests for > sure > > and I will upload to registry (gotta do it eventually :P) > > > > -Steve > > > > > > > > > > On Thu, Jul 25, 2013 at 6:21 AM, Andrew Grieve > > wrote: > > > > > Steve - If you mention the CB- in the commit description then a bot > > > will automatically add a comment to the issue with the commit link. The > > > issues aren't very useful if they don't point to the commits that fix > > them. > > > > > > For the names - just wanted to verify whether it was the name field or > > the > > > id field that can't have caps/spaces? If it's the name, then ID seems a > > bit > > > redundant. Either way - I think it's important to have some sort of > > common > > > prefix for cordova-core plugins. E.g. core-vibration, or > > > org.apache.cordova.vibration. > > > > > > I think any merge into master is worthy of a release bug. That way you > > can > > > link it with the commit that bumps the package.json version. Probably > one > > > bug for all the plugins being released is fine though. In the release > > bug, > > > I think you should state what you tested, mobile-spec is the goto, but > in > > > this case, you may want to say that you tested uploading to the plugins > > > registry. > > > > > > > > > On Wed, Jul 24, 2013 at 6:26 PM, Shazron wrote: > > > > > > > plugin.xml changes only correct? IMO bump the version and run the > steps > > > > here to test plugin add: > > http://wiki.apache.org/cordova/WorkingWithThree > > > > > > > > > > > > > > > > > > > > On Wed, Jul 24, 2013 at 3:03 PM, Steven Gill > > > > > wrote: > > > > > > > > > So I just added a dev branch for all of the plugins and finished > the > > > > issues > > > > > [1] [2] [3]. All three of these were minor fixes and I don't > believe > > > > > require retesting all of the plugins on every platform. What should > > my > > > > next > > > > > steps be? I know if I merge into master, I should bump the version > > for > > > > all > > > > > of them to 0.1.1. Is this something I should create a release bug > for > > > and > > > > > get tested before merging into master? > > > > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/CB-4371 > > > > > [2] https://issues.apache.org/jira/browse/CB-4370 > > > > > [3] https://issues.apache.org/jira/browse/CB-4338 > > > > > > > > > > > > > > > On Mon, Jul 22, 2013 at 12:41 PM, Brian LeRoux wrote: > > > > > > > > > > > Like that > > > > > > > > > > > > On Mon, Jul 22, 2013 at 3:33 PM, Andrew Grieve < > > agri...@chromium.org > > > > > > > > > > wrote: > > > > > > > Oh! Oh! Perhaps have multiple definitions based on CDV version. > > > e.g.: > > > > > > > > > > > > > > > > > > > > > refs/head/2.8.x > > > > > > > > > > > > > > > > > > > > > refs/tags/stable > > > > > > > > > > > > > > > > > > > > > > > > > > > > Then, when someone plugman installs the git URL, it can fetch > it > > > and > > > > > > > checkout a version that best matches your cordova version. > > > > > > > Then, when you update your cordova version, it can go through > > your > > > > > > plugins > > > > > > > and update them to different branches (unless you glue them to > a > > > ref > > > > > as a > > > > > > > part of your install URL) > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jul 22, 2013 at 2:44 PM, Braden Shepherdson < > > > > > bra...@chromium.org > > > > > > >wrote: > > > > > > > > > > > > > >> The model I had always imagined was that we would do something > > > > similar > > > > > > to > > > > > > >> npm: Plugin authors decide what the default ref is for their > > > plugin. > > > > > > Could > > > > > > >> be master, some other branch, a tag, a hash. That's what the > > > > discovery > > > > > > tool > > > > > > >> will return when a user asks to add that plugin without > > explicitly > > > > > > >> specifying a version. I think this is a good idea we should > > > > implement > > > > > > too. > > > > > > >> > > > > > > >> Braden > > > > > > >> > > > > > > >> > > > > > > >> On Fri, Jul 19, 2013 at 10:16 AM, Andrew Grieve < > > > > agri...@chromium.org > > > > > > >> >wrote: > > > > > > >> >
Re: Plugin / Platform mismatch problems
Anis - can we make it use id instead? I think that's more inline with the purpose of the field. Maybe we should remove the name field? I can't think of a meaningful distinction between name and id given that we already have a description field. On Thu, Jul 25, 2013 at 2:35 PM, Steven Gill wrote: > Thanks for the advice Shaz and Andrew. > > I will make sure to mention the issue in the commit so the bot picks it up. > > Just talked to Anis and he says it is the name tag and not the ID. I could > go and rename all of the core plugins to start with 'core-' if that makes > more sense to people. I like it. Distinguishes core plugins from community > ones. > > I will make sure to do a release bug once ready. Mobile-spec tests for sure > and I will upload to registry (gotta do it eventually :P) > > -Steve > > > > > On Thu, Jul 25, 2013 at 6:21 AM, Andrew Grieve > wrote: > > > Steve - If you mention the CB- in the commit description then a bot > > will automatically add a comment to the issue with the commit link. The > > issues aren't very useful if they don't point to the commits that fix > them. > > > > For the names - just wanted to verify whether it was the name field or > the > > id field that can't have caps/spaces? If it's the name, then ID seems a > bit > > redundant. Either way - I think it's important to have some sort of > common > > prefix for cordova-core plugins. E.g. core-vibration, or > > org.apache.cordova.vibration. > > > > I think any merge into master is worthy of a release bug. That way you > can > > link it with the commit that bumps the package.json version. Probably one > > bug for all the plugins being released is fine though. In the release > bug, > > I think you should state what you tested, mobile-spec is the goto, but in > > this case, you may want to say that you tested uploading to the plugins > > registry. > > > > > > On Wed, Jul 24, 2013 at 6:26 PM, Shazron wrote: > > > > > plugin.xml changes only correct? IMO bump the version and run the steps > > > here to test plugin add: > http://wiki.apache.org/cordova/WorkingWithThree > > > > > > > > > > > > > > > On Wed, Jul 24, 2013 at 3:03 PM, Steven Gill > > > wrote: > > > > > > > So I just added a dev branch for all of the plugins and finished the > > > issues > > > > [1] [2] [3]. All three of these were minor fixes and I don't believe > > > > require retesting all of the plugins on every platform. What should > my > > > next > > > > steps be? I know if I merge into master, I should bump the version > for > > > all > > > > of them to 0.1.1. Is this something I should create a release bug for > > and > > > > get tested before merging into master? > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/CB-4371 > > > > [2] https://issues.apache.org/jira/browse/CB-4370 > > > > [3] https://issues.apache.org/jira/browse/CB-4338 > > > > > > > > > > > > On Mon, Jul 22, 2013 at 12:41 PM, Brian LeRoux wrote: > > > > > > > > > Like that > > > > > > > > > > On Mon, Jul 22, 2013 at 3:33 PM, Andrew Grieve < > agri...@chromium.org > > > > > > > > wrote: > > > > > > Oh! Oh! Perhaps have multiple definitions based on CDV version. > > e.g.: > > > > > > > > > > > > > > > > > > refs/head/2.8.x > > > > > > > > > > > > > > > > > > refs/tags/stable > > > > > > > > > > > > > > > > > > > > > > > > Then, when someone plugman installs the git URL, it can fetch it > > and > > > > > > checkout a version that best matches your cordova version. > > > > > > Then, when you update your cordova version, it can go through > your > > > > > plugins > > > > > > and update them to different branches (unless you glue them to a > > ref > > > > as a > > > > > > part of your install URL) > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jul 22, 2013 at 2:44 PM, Braden Shepherdson < > > > > bra...@chromium.org > > > > > >wrote: > > > > > > > > > > > >> The model I had always imagined was that we would do something > > > similar > > > > > to > > > > > >> npm: Plugin authors decide what the default ref is for their > > plugin. > > > > > Could > > > > > >> be master, some other branch, a tag, a hash. That's what the > > > discovery > > > > > tool > > > > > >> will return when a user asks to add that plugin without > explicitly > > > > > >> specifying a version. I think this is a good idea we should > > > implement > > > > > too. > > > > > >> > > > > > >> Braden > > > > > >> > > > > > >> > > > > > >> On Fri, Jul 19, 2013 at 10:16 AM, Andrew Grieve < > > > agri...@chromium.org > > > > > >> >wrote: > > > > > >> > > > > > >> > I think it's true that: > > > > > >> > > > > > > >> > 1. CLI downloads tagged versions of platforms > > > > > >> > 2. Plugman downloads plugins from "master" branch > > > > > >> > > > > > > >> > This means that we can't check any code into plugin master > > > branches > > > > > >> without > > > > > >> > them going live immediately. > > > > > >> > > > > > > >> > Best solution would be to change plugman to download from a > tag > >
Re: Plugin / Platform mismatch problems
Should probably tie into plugman as well, to not refer to plugins via their id? Does this make the id useless? Or does it provide value in a multi-plugin-registry reality? On 7/25/13 11:35 AM, "Steven Gill" wrote: >Thanks for the advice Shaz and Andrew. > >I will make sure to mention the issue in the commit so the bot picks it >up. > >Just talked to Anis and he says it is the name tag and not the ID. I could >go and rename all of the core plugins to start with 'core-' if that makes >more sense to people. I like it. Distinguishes core plugins from community >ones. > >I will make sure to do a release bug once ready. Mobile-spec tests for >sure >and I will upload to registry (gotta do it eventually :P) > >-Steve > > > > >On Thu, Jul 25, 2013 at 6:21 AM, Andrew Grieve >wrote: > >> Steve - If you mention the CB- in the commit description then a bot >> will automatically add a comment to the issue with the commit link. The >> issues aren't very useful if they don't point to the commits that fix >>them. >> >> For the names - just wanted to verify whether it was the name field or >>the >> id field that can't have caps/spaces? If it's the name, then ID seems a >>bit >> redundant. Either way - I think it's important to have some sort of >>common >> prefix for cordova-core plugins. E.g. core-vibration, or >> org.apache.cordova.vibration. >> >> I think any merge into master is worthy of a release bug. That way you >>can >> link it with the commit that bumps the package.json version. Probably >>one >> bug for all the plugins being released is fine though. In the release >>bug, >> I think you should state what you tested, mobile-spec is the goto, but >>in >> this case, you may want to say that you tested uploading to the plugins >> registry. >> >> >> On Wed, Jul 24, 2013 at 6:26 PM, Shazron wrote: >> >> > plugin.xml changes only correct? IMO bump the version and run the >>steps >> > here to test plugin add: >>http://wiki.apache.org/cordova/WorkingWithThree >> > >> > >> > >> > >> > On Wed, Jul 24, 2013 at 3:03 PM, Steven Gill >> > wrote: >> > >> > > So I just added a dev branch for all of the plugins and finished the >> > issues >> > > [1] [2] [3]. All three of these were minor fixes and I don't believe >> > > require retesting all of the plugins on every platform. What should >>my >> > next >> > > steps be? I know if I merge into master, I should bump the version >>for >> > all >> > > of them to 0.1.1. Is this something I should create a release bug >>for >> and >> > > get tested before merging into master? >> > > >> > > >> > > [1] https://issues.apache.org/jira/browse/CB-4371 >> > > [2] https://issues.apache.org/jira/browse/CB-4370 >> > > [3] https://issues.apache.org/jira/browse/CB-4338 >> > > >> > > >> > > On Mon, Jul 22, 2013 at 12:41 PM, Brian LeRoux wrote: >> > > >> > > > Like that >> > > > >> > > > On Mon, Jul 22, 2013 at 3:33 PM, Andrew Grieve >>> > >> > > > wrote: >> > > > > Oh! Oh! Perhaps have multiple definitions based on CDV version. >> e.g.: >> > > > > >> > > > > >> > > > > refs/head/2.8.x >> > > > > >> > > > > >> > > > > refs/tags/stable >> > > > > >> > > > > >> > > > > >> > > > > Then, when someone plugman installs the git URL, it can fetch it >> and >> > > > > checkout a version that best matches your cordova version. >> > > > > Then, when you update your cordova version, it can go through >>your >> > > > plugins >> > > > > and update them to different branches (unless you glue them to a >> ref >> > > as a >> > > > > part of your install URL) >> > > > > >> > > > > >> > > > > >> > > > > On Mon, Jul 22, 2013 at 2:44 PM, Braden Shepherdson < >> > > bra...@chromium.org >> > > > >wrote: >> > > > > >> > > > >> The model I had always imagined was that we would do something >> > similar >> > > > to >> > > > >> npm: Plugin authors decide what the default ref is for their >> plugin. >> > > > Could >> > > > >> be master, some other branch, a tag, a hash. That's what the >> > discovery >> > > > tool >> > > > >> will return when a user asks to add that plugin without >>explicitly >> > > > >> specifying a version. I think this is a good idea we should >> > implement >> > > > too. >> > > > >> >> > > > >> Braden >> > > > >> >> > > > >> >> > > > >> On Fri, Jul 19, 2013 at 10:16 AM, Andrew Grieve < >> > agri...@chromium.org >> > > > >> >wrote: >> > > > >> >> > > > >> > I think it's true that: >> > > > >> > >> > > > >> > 1. CLI downloads tagged versions of platforms >> > > > >> > 2. Plugman downloads plugins from "master" branch >> > > > >> > >> > > > >> > This means that we can't check any code into plugin master >> > branches >> > > > >> without >> > > > >> > them going live immediately. >> > > > >> > >> > > > >> > Best solution would be to change plugman to download from a >>tag >> by >> > > > >> default, >> > > > >> > but a bit late for that now... >> > > > >> > >> > > > >> > Instead, I think we should change all development on plugins: >> > > > >> > - Commit only to "dev" branch. >> > > > >> > - W
Re: Plugin / Platform mismatch problems
Thanks for the advice Shaz and Andrew. I will make sure to mention the issue in the commit so the bot picks it up. Just talked to Anis and he says it is the name tag and not the ID. I could go and rename all of the core plugins to start with 'core-' if that makes more sense to people. I like it. Distinguishes core plugins from community ones. I will make sure to do a release bug once ready. Mobile-spec tests for sure and I will upload to registry (gotta do it eventually :P) -Steve On Thu, Jul 25, 2013 at 6:21 AM, Andrew Grieve wrote: > Steve - If you mention the CB- in the commit description then a bot > will automatically add a comment to the issue with the commit link. The > issues aren't very useful if they don't point to the commits that fix them. > > For the names - just wanted to verify whether it was the name field or the > id field that can't have caps/spaces? If it's the name, then ID seems a bit > redundant. Either way - I think it's important to have some sort of common > prefix for cordova-core plugins. E.g. core-vibration, or > org.apache.cordova.vibration. > > I think any merge into master is worthy of a release bug. That way you can > link it with the commit that bumps the package.json version. Probably one > bug for all the plugins being released is fine though. In the release bug, > I think you should state what you tested, mobile-spec is the goto, but in > this case, you may want to say that you tested uploading to the plugins > registry. > > > On Wed, Jul 24, 2013 at 6:26 PM, Shazron wrote: > > > plugin.xml changes only correct? IMO bump the version and run the steps > > here to test plugin add: http://wiki.apache.org/cordova/WorkingWithThree > > > > > > > > > > On Wed, Jul 24, 2013 at 3:03 PM, Steven Gill > > wrote: > > > > > So I just added a dev branch for all of the plugins and finished the > > issues > > > [1] [2] [3]. All three of these were minor fixes and I don't believe > > > require retesting all of the plugins on every platform. What should my > > next > > > steps be? I know if I merge into master, I should bump the version for > > all > > > of them to 0.1.1. Is this something I should create a release bug for > and > > > get tested before merging into master? > > > > > > > > > [1] https://issues.apache.org/jira/browse/CB-4371 > > > [2] https://issues.apache.org/jira/browse/CB-4370 > > > [3] https://issues.apache.org/jira/browse/CB-4338 > > > > > > > > > On Mon, Jul 22, 2013 at 12:41 PM, Brian LeRoux wrote: > > > > > > > Like that > > > > > > > > On Mon, Jul 22, 2013 at 3:33 PM, Andrew Grieve > > > > > wrote: > > > > > Oh! Oh! Perhaps have multiple definitions based on CDV version. > e.g.: > > > > > > > > > > > > > > > refs/head/2.8.x > > > > > > > > > > > > > > > refs/tags/stable > > > > > > > > > > > > > > > > > > > > Then, when someone plugman installs the git URL, it can fetch it > and > > > > > checkout a version that best matches your cordova version. > > > > > Then, when you update your cordova version, it can go through your > > > > plugins > > > > > and update them to different branches (unless you glue them to a > ref > > > as a > > > > > part of your install URL) > > > > > > > > > > > > > > > > > > > > On Mon, Jul 22, 2013 at 2:44 PM, Braden Shepherdson < > > > bra...@chromium.org > > > > >wrote: > > > > > > > > > >> The model I had always imagined was that we would do something > > similar > > > > to > > > > >> npm: Plugin authors decide what the default ref is for their > plugin. > > > > Could > > > > >> be master, some other branch, a tag, a hash. That's what the > > discovery > > > > tool > > > > >> will return when a user asks to add that plugin without explicitly > > > > >> specifying a version. I think this is a good idea we should > > implement > > > > too. > > > > >> > > > > >> Braden > > > > >> > > > > >> > > > > >> On Fri, Jul 19, 2013 at 10:16 AM, Andrew Grieve < > > agri...@chromium.org > > > > >> >wrote: > > > > >> > > > > >> > I think it's true that: > > > > >> > > > > > >> > 1. CLI downloads tagged versions of platforms > > > > >> > 2. Plugman downloads plugins from "master" branch > > > > >> > > > > > >> > This means that we can't check any code into plugin master > > branches > > > > >> without > > > > >> > them going live immediately. > > > > >> > > > > > >> > Best solution would be to change plugman to download from a tag > by > > > > >> default, > > > > >> > but a bit late for that now... > > > > >> > > > > > >> > Instead, I think we should change all development on plugins: > > > > >> > - Commit only to "dev" branch. > > > > >> > - When we want to push an update, we should file a release bug > for > > > the > > > > >> > plugin, test on all platforms > > > > >> > Case 1: The changes work with 3.0 cordova: then merge into > master > > > > (only > > > > >> if > > > > >> > it works of course) > > > > >> > Case 2: The changes require a platform API that hasn't been > > release > > > > yet: > > > > >> > Wait and release afte
Re: Plugin / Platform mismatch problems
Steve - If you mention the CB- in the commit description then a bot will automatically add a comment to the issue with the commit link. The issues aren't very useful if they don't point to the commits that fix them. For the names - just wanted to verify whether it was the name field or the id field that can't have caps/spaces? If it's the name, then ID seems a bit redundant. Either way - I think it's important to have some sort of common prefix for cordova-core plugins. E.g. core-vibration, or org.apache.cordova.vibration. I think any merge into master is worthy of a release bug. That way you can link it with the commit that bumps the package.json version. Probably one bug for all the plugins being released is fine though. In the release bug, I think you should state what you tested, mobile-spec is the goto, but in this case, you may want to say that you tested uploading to the plugins registry. On Wed, Jul 24, 2013 at 6:26 PM, Shazron wrote: > plugin.xml changes only correct? IMO bump the version and run the steps > here to test plugin add: http://wiki.apache.org/cordova/WorkingWithThree > > > > > On Wed, Jul 24, 2013 at 3:03 PM, Steven Gill > wrote: > > > So I just added a dev branch for all of the plugins and finished the > issues > > [1] [2] [3]. All three of these were minor fixes and I don't believe > > require retesting all of the plugins on every platform. What should my > next > > steps be? I know if I merge into master, I should bump the version for > all > > of them to 0.1.1. Is this something I should create a release bug for and > > get tested before merging into master? > > > > > > [1] https://issues.apache.org/jira/browse/CB-4371 > > [2] https://issues.apache.org/jira/browse/CB-4370 > > [3] https://issues.apache.org/jira/browse/CB-4338 > > > > > > On Mon, Jul 22, 2013 at 12:41 PM, Brian LeRoux wrote: > > > > > Like that > > > > > > On Mon, Jul 22, 2013 at 3:33 PM, Andrew Grieve > > > wrote: > > > > Oh! Oh! Perhaps have multiple definitions based on CDV version. e.g.: > > > > > > > > > > > > refs/head/2.8.x > > > > > > > > > > > > refs/tags/stable > > > > > > > > > > > > > > > > Then, when someone plugman installs the git URL, it can fetch it and > > > > checkout a version that best matches your cordova version. > > > > Then, when you update your cordova version, it can go through your > > > plugins > > > > and update them to different branches (unless you glue them to a ref > > as a > > > > part of your install URL) > > > > > > > > > > > > > > > > On Mon, Jul 22, 2013 at 2:44 PM, Braden Shepherdson < > > bra...@chromium.org > > > >wrote: > > > > > > > >> The model I had always imagined was that we would do something > similar > > > to > > > >> npm: Plugin authors decide what the default ref is for their plugin. > > > Could > > > >> be master, some other branch, a tag, a hash. That's what the > discovery > > > tool > > > >> will return when a user asks to add that plugin without explicitly > > > >> specifying a version. I think this is a good idea we should > implement > > > too. > > > >> > > > >> Braden > > > >> > > > >> > > > >> On Fri, Jul 19, 2013 at 10:16 AM, Andrew Grieve < > agri...@chromium.org > > > >> >wrote: > > > >> > > > >> > I think it's true that: > > > >> > > > > >> > 1. CLI downloads tagged versions of platforms > > > >> > 2. Plugman downloads plugins from "master" branch > > > >> > > > > >> > This means that we can't check any code into plugin master > branches > > > >> without > > > >> > them going live immediately. > > > >> > > > > >> > Best solution would be to change plugman to download from a tag by > > > >> default, > > > >> > but a bit late for that now... > > > >> > > > > >> > Instead, I think we should change all development on plugins: > > > >> > - Commit only to "dev" branch. > > > >> > - When we want to push an update, we should file a release bug for > > the > > > >> > plugin, test on all platforms > > > >> > Case 1: The changes work with 3.0 cordova: then merge into master > > > (only > > > >> if > > > >> > it works of course) > > > >> > Case 2: The changes require a platform API that hasn't been > release > > > yet: > > > >> > Wait and release after the next cordova core release. > > > >> > > > > >> > > > > >> > Any other ideas? > > > >> > > > > >> > > > > > >
Re: Plugin / Platform mismatch problems
plugin.xml changes only correct? IMO bump the version and run the steps here to test plugin add: http://wiki.apache.org/cordova/WorkingWithThree On Wed, Jul 24, 2013 at 3:03 PM, Steven Gill wrote: > So I just added a dev branch for all of the plugins and finished the issues > [1] [2] [3]. All three of these were minor fixes and I don't believe > require retesting all of the plugins on every platform. What should my next > steps be? I know if I merge into master, I should bump the version for all > of them to 0.1.1. Is this something I should create a release bug for and > get tested before merging into master? > > > [1] https://issues.apache.org/jira/browse/CB-4371 > [2] https://issues.apache.org/jira/browse/CB-4370 > [3] https://issues.apache.org/jira/browse/CB-4338 > > > On Mon, Jul 22, 2013 at 12:41 PM, Brian LeRoux wrote: > > > Like that > > > > On Mon, Jul 22, 2013 at 3:33 PM, Andrew Grieve > > wrote: > > > Oh! Oh! Perhaps have multiple definitions based on CDV version. e.g.: > > > > > > > > > refs/head/2.8.x > > > > > > > > > refs/tags/stable > > > > > > > > > > > > Then, when someone plugman installs the git URL, it can fetch it and > > > checkout a version that best matches your cordova version. > > > Then, when you update your cordova version, it can go through your > > plugins > > > and update them to different branches (unless you glue them to a ref > as a > > > part of your install URL) > > > > > > > > > > > > On Mon, Jul 22, 2013 at 2:44 PM, Braden Shepherdson < > bra...@chromium.org > > >wrote: > > > > > >> The model I had always imagined was that we would do something similar > > to > > >> npm: Plugin authors decide what the default ref is for their plugin. > > Could > > >> be master, some other branch, a tag, a hash. That's what the discovery > > tool > > >> will return when a user asks to add that plugin without explicitly > > >> specifying a version. I think this is a good idea we should implement > > too. > > >> > > >> Braden > > >> > > >> > > >> On Fri, Jul 19, 2013 at 10:16 AM, Andrew Grieve > >> >wrote: > > >> > > >> > I think it's true that: > > >> > > > >> > 1. CLI downloads tagged versions of platforms > > >> > 2. Plugman downloads plugins from "master" branch > > >> > > > >> > This means that we can't check any code into plugin master branches > > >> without > > >> > them going live immediately. > > >> > > > >> > Best solution would be to change plugman to download from a tag by > > >> default, > > >> > but a bit late for that now... > > >> > > > >> > Instead, I think we should change all development on plugins: > > >> > - Commit only to "dev" branch. > > >> > - When we want to push an update, we should file a release bug for > the > > >> > plugin, test on all platforms > > >> > Case 1: The changes work with 3.0 cordova: then merge into master > > (only > > >> if > > >> > it works of course) > > >> > Case 2: The changes require a platform API that hasn't been release > > yet: > > >> > Wait and release after the next cordova core release. > > >> > > > >> > > > >> > Any other ideas? > > >> > > > >> > > >
Re: Plugin / Platform mismatch problems
So I just added a dev branch for all of the plugins and finished the issues [1] [2] [3]. All three of these were minor fixes and I don't believe require retesting all of the plugins on every platform. What should my next steps be? I know if I merge into master, I should bump the version for all of them to 0.1.1. Is this something I should create a release bug for and get tested before merging into master? [1] https://issues.apache.org/jira/browse/CB-4371 [2] https://issues.apache.org/jira/browse/CB-4370 [3] https://issues.apache.org/jira/browse/CB-4338 On Mon, Jul 22, 2013 at 12:41 PM, Brian LeRoux wrote: > Like that > > On Mon, Jul 22, 2013 at 3:33 PM, Andrew Grieve > wrote: > > Oh! Oh! Perhaps have multiple definitions based on CDV version. e.g.: > > > > > > refs/head/2.8.x > > > > > > refs/tags/stable > > > > > > > > Then, when someone plugman installs the git URL, it can fetch it and > > checkout a version that best matches your cordova version. > > Then, when you update your cordova version, it can go through your > plugins > > and update them to different branches (unless you glue them to a ref as a > > part of your install URL) > > > > > > > > On Mon, Jul 22, 2013 at 2:44 PM, Braden Shepherdson >wrote: > > > >> The model I had always imagined was that we would do something similar > to > >> npm: Plugin authors decide what the default ref is for their plugin. > Could > >> be master, some other branch, a tag, a hash. That's what the discovery > tool > >> will return when a user asks to add that plugin without explicitly > >> specifying a version. I think this is a good idea we should implement > too. > >> > >> Braden > >> > >> > >> On Fri, Jul 19, 2013 at 10:16 AM, Andrew Grieve >> >wrote: > >> > >> > I think it's true that: > >> > > >> > 1. CLI downloads tagged versions of platforms > >> > 2. Plugman downloads plugins from "master" branch > >> > > >> > This means that we can't check any code into plugin master branches > >> without > >> > them going live immediately. > >> > > >> > Best solution would be to change plugman to download from a tag by > >> default, > >> > but a bit late for that now... > >> > > >> > Instead, I think we should change all development on plugins: > >> > - Commit only to "dev" branch. > >> > - When we want to push an update, we should file a release bug for the > >> > plugin, test on all platforms > >> > Case 1: The changes work with 3.0 cordova: then merge into master > (only > >> if > >> > it works of course) > >> > Case 2: The changes require a platform API that hasn't been release > yet: > >> > Wait and release after the next cordova core release. > >> > > >> > > >> > Any other ideas? > >> > > >> >
Re: Plugin / Platform mismatch problems
Like that On Mon, Jul 22, 2013 at 3:33 PM, Andrew Grieve wrote: > Oh! Oh! Perhaps have multiple definitions based on CDV version. e.g.: > > > refs/head/2.8.x > > > refs/tags/stable > > > > Then, when someone plugman installs the git URL, it can fetch it and > checkout a version that best matches your cordova version. > Then, when you update your cordova version, it can go through your plugins > and update them to different branches (unless you glue them to a ref as a > part of your install URL) > > > > On Mon, Jul 22, 2013 at 2:44 PM, Braden Shepherdson > wrote: > >> The model I had always imagined was that we would do something similar to >> npm: Plugin authors decide what the default ref is for their plugin. Could >> be master, some other branch, a tag, a hash. That's what the discovery tool >> will return when a user asks to add that plugin without explicitly >> specifying a version. I think this is a good idea we should implement too. >> >> Braden >> >> >> On Fri, Jul 19, 2013 at 10:16 AM, Andrew Grieve > >wrote: >> >> > I think it's true that: >> > >> > 1. CLI downloads tagged versions of platforms >> > 2. Plugman downloads plugins from "master" branch >> > >> > This means that we can't check any code into plugin master branches >> without >> > them going live immediately. >> > >> > Best solution would be to change plugman to download from a tag by >> default, >> > but a bit late for that now... >> > >> > Instead, I think we should change all development on plugins: >> > - Commit only to "dev" branch. >> > - When we want to push an update, we should file a release bug for the >> > plugin, test on all platforms >> > Case 1: The changes work with 3.0 cordova: then merge into master (only >> if >> > it works of course) >> > Case 2: The changes require a platform API that hasn't been release yet: >> > Wait and release after the next cordova core release. >> > >> > >> > Any other ideas? >> > >>
Re: Plugin / Platform mismatch problems
Oh! Oh! Perhaps have multiple definitions based on CDV version. e.g.: refs/head/2.8.x refs/tags/stable Then, when someone plugman installs the git URL, it can fetch it and checkout a version that best matches your cordova version. Then, when you update your cordova version, it can go through your plugins and update them to different branches (unless you glue them to a ref as a part of your install URL) On Mon, Jul 22, 2013 at 2:44 PM, Braden Shepherdson wrote: > The model I had always imagined was that we would do something similar to > npm: Plugin authors decide what the default ref is for their plugin. Could > be master, some other branch, a tag, a hash. That's what the discovery tool > will return when a user asks to add that plugin without explicitly > specifying a version. I think this is a good idea we should implement too. > > Braden > > > On Fri, Jul 19, 2013 at 10:16 AM, Andrew Grieve >wrote: > > > I think it's true that: > > > > 1. CLI downloads tagged versions of platforms > > 2. Plugman downloads plugins from "master" branch > > > > This means that we can't check any code into plugin master branches > without > > them going live immediately. > > > > Best solution would be to change plugman to download from a tag by > default, > > but a bit late for that now... > > > > Instead, I think we should change all development on plugins: > > - Commit only to "dev" branch. > > - When we want to push an update, we should file a release bug for the > > plugin, test on all platforms > > Case 1: The changes work with 3.0 cordova: then merge into master (only > if > > it works of course) > > Case 2: The changes require a platform API that hasn't been release yet: > > Wait and release after the next cordova core release. > > > > > > Any other ideas? > > >
Re: Plugin / Platform mismatch problems
The model I had always imagined was that we would do something similar to npm: Plugin authors decide what the default ref is for their plugin. Could be master, some other branch, a tag, a hash. That's what the discovery tool will return when a user asks to add that plugin without explicitly specifying a version. I think this is a good idea we should implement too. Braden On Fri, Jul 19, 2013 at 10:16 AM, Andrew Grieve wrote: > I think it's true that: > > 1. CLI downloads tagged versions of platforms > 2. Plugman downloads plugins from "master" branch > > This means that we can't check any code into plugin master branches without > them going live immediately. > > Best solution would be to change plugman to download from a tag by default, > but a bit late for that now... > > Instead, I think we should change all development on plugins: > - Commit only to "dev" branch. > - When we want to push an update, we should file a release bug for the > plugin, test on all platforms > Case 1: The changes work with 3.0 cordova: then merge into master (only if > it works of course) > Case 2: The changes require a platform API that hasn't been release yet: > Wait and release after the next cordova core release. > > > Any other ideas? >
Re: Plugin / Platform mismatch problems
Yeah this entire bit needs a lot of love for sure. I think Anis' registry work should solve the big current issues here. In the mean time your proposal sounds fine to me. Only thing I would add is to increment the version attribute in the plugin.xml every time a merge back into master happens (so if people submit issues with a plugin we can track which version they are using) On 7/19/13 10:16 AM, "Andrew Grieve" wrote: >I think it's true that: > >1. CLI downloads tagged versions of platforms >2. Plugman downloads plugins from "master" branch > >This means that we can't check any code into plugin master branches >without >them going live immediately. > >Best solution would be to change plugman to download from a tag by >default, >but a bit late for that now... > >Instead, I think we should change all development on plugins: >- Commit only to "dev" branch. >- When we want to push an update, we should file a release bug for the >plugin, test on all platforms >Case 1: The changes work with 3.0 cordova: then merge into master (only if >it works of course) >Case 2: The changes require a platform API that hasn't been release yet: >Wait and release after the next cordova core release. > > >Any other ideas?
Plugin / Platform mismatch problems
I think it's true that: 1. CLI downloads tagged versions of platforms 2. Plugman downloads plugins from "master" branch This means that we can't check any code into plugin master branches without them going live immediately. Best solution would be to change plugman to download from a tag by default, but a bit late for that now... Instead, I think we should change all development on plugins: - Commit only to "dev" branch. - When we want to push an update, we should file a release bug for the plugin, test on all platforms Case 1: The changes work with 3.0 cordova: then merge into master (only if it works of course) Case 2: The changes require a platform API that hasn't been release yet: Wait and release after the next cordova core release. Any other ideas?
