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