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