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" <agri...@chromium.org> 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 <benn.ma...@gmail.com> 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 <stevengil...@gmail.com> >> 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 <brettr...@gmail.com> >> 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 <shaz...@gmail.com> 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-XXXX 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 <shaz...@gmail.com> >> 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 <b...@brian.io> >> > 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.: >> > > >>>>>>>> >> > > >>>>>>>> <engine min-cdv-version="2.8" max-cdv-version="2.8"> >> > > >>>>>>>> <default-git-ref>refs/head/2.8.x</default-git-ref> >> > > >>>>>>>> </engine> >> > > >>>>>>>> <engine min-cdv-version="2.9"> >> > > >>>>>>>> <default-git-ref>refs/tags/stable</default-git-ref> >> > > >>>>>>>> </engine> >> > > >>>>>>>> >> > > >>>>>>>> >> > > >>>>>>>> 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? >> > > >>>>>>>>>> >> > > >>>>>>>>> >> > > >>>>>>> >> > > >>>>>> >> > > >>>>> >> > > >>>> >> > > >>> >> > > >> >> > > >> > > >> > >>
