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