Yeah we can use id and keep name around for human readable purpose. I am fine with it. I just think that typing giant package names is just not user friendly from a developer's perspective. Maybe it's just me.
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? >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>> >> >>>>>> >> >>>>> >> >>>> >> >>> >> >> >> >>
