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? > > > >>>>>>>>>> > > > >>>>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>>> > > > >>>> > > > >>> > > > >> > > > > > > > > >
