I'll try to summarize where we were before and where we are at currently. In The Beginning: - we spec'ed an `id` attribute to the plugin manifest under the pretense of having a unique identifier (generally a good idea), and a preemptive approach at easing a situation where we have a multi-registry universe (For example: BlackBerry, Apache, Google all hosting plugin registries) - the <name> element was to be a human-readable, "pretty" label. It can have spaces, apostrophes, etc. just like the <name> element in config.xml
In The Present: - we are at the point where we are using an existing system (npm) that has different constraints on uniquely identifying a project. Npm uses a name, with no spaces, no underscores, and some other char constraints. - which leads us to our current conundrum: which field do we use to uniquely identify a plugin, and which solution should we employ to map between our plugin specification for naming / id'ing packages vs. Npm's. There are many different ways to solve this problem, each with varying degrees of difficulty to implement and each having a different answer to the question of "how much will we need to diverge from npm to support it": - using a plugin id as the npm "name" - using a plugin's "cleaned up" <name> contents (no spaces or funny characters) as the npm name Finally, discovery is the last use case that needs to be addressed here. What is npm's current strategy and what do we want to support? On 7/26/13 11:21 AM, "Anis KADRI" <anis.ka...@gmail.com> wrote: >Exactly! Only the ones we need too! We're already doing this for >name/version/description so it would just be a few more. > >On Fri, Jul 26, 2013 at 11:19 AM, Filip Maj <f...@adobe.com> wrote: >> Ahh yeah. Some kind of at-publish-time conversion of certain plugin.xml >> fields to json fields? >> >> On 7/26/13 10:27 AM, "Anis KADRI" <anis.ka...@gmail.com> wrote: >> >>>I think XML is not a query friendly language. I suggest we add an >>>engine field initially and then add fields as we need them. I suspect >>>we won't be needing the bulk of plugin.xml in the registry. I have to >>>experiment with custom fields still but it seems possible. I will >>>report back sometime today. >>> >>>On Fri, Jul 26, 2013 at 9:23 AM, Filip Maj <f...@adobe.com> wrote: >>>> I think this was brought up before, but why not store the plugin xml >>>>in >>>> its entirety? I can us needing more bits down the road, such as >>>> dependencies and platform version requirements. >>>> >>>> >>>> On 7/26/13 7:32 AM, "Andrew Grieve" <agri...@chromium.org> wrote: >>>> >>>>>That all sounds good, but let's talk more about the git ref part: >>>>> >>>>>It looks like our npm-based directory system is going to host the .tgz >>>>>of >>>>>the plugins, so it won't matter what git ref the .tgz maps back to >>>>>unless >>>>>we think that a lot of people are not going to use our directory >>>>>service. >>>>> >>>>>One thing that would be useful though, is a way to list plugins >>>>>compatible >>>>>with your version of cordova (e.g. query for the latest version of >>>>>cordova-plugin-file that is compatible with 3.0.0). I think all that's >>>>>required here is to store the engine tag in the couchdb metadata >>>>>alongside >>>>>the tgz. >>>>> >>>>> >>>>>On Thu, Jul 25, 2013 at 6:38 PM, Benn Mapes <benn.ma...@gmail.com> >>>>>wrote: >>>>> >>>>>> +1 to brett's comments. >>>>>> Name - Human Readable name of the plugin to be used in the context >>>>>>of >>>>>> plugin >>>>>> discovery. >>>>>> ID - unique id used by tools to reference the plugin >>>>>> Description - sentence+ about the plugin (optional?) >>>>>> >>>>>> As for how plugins should be loaded I liked Braden's suggestion that >>>>>>plugin >>>>>> authors decide what the default ref is for their plugin. Default >>>>>>should >>>>>>be >>>>>> master if no ref is provided. >>>>>> >>>>>> >>>>>> 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? >>>>>> > > >>>>>>>>>> >>>>>> > > >>>>>>>>> >>>>>> > > >>>>>>> >>>>>> > > >>>>>> >>>>>> > > >>>>> >>>>>> > > >>>> >>>>>> > > >>> >>>>>> > > >> >>>>>> > > >>>>>> > > >>>>>> > >>>>>> >>>> >>
