Should probably tie into plugman as well, to not refer to plugins via their id?
Does this make the id useless? Or does it provide value in a multi-plugin-registry reality? On 7/25/13 11:35 AM, "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? >> > > > >> > >> > > > >> >> > > > >> > > >> > >>
