Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| plugin_store_guidelines [2017/11/27 17:00] – [Release Requirements] jay | plugin_store_guidelines [2026/04/07 18:27] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ===== Plugin Store Submission Guidelines ===== | ||
| + | This document outlines the rules for submitting a plugin to the [[http:// | ||
| + | |||
| + | **<color # | ||
| + | ==== Creating Your Developer Account ==== | ||
| + | If you haven' | ||
| + | |||
| + | {{: | ||
| + | |||
| + | Please read through the entire top section of that page as it contains important information. | ||
| + | |||
| + | **Warning**: | ||
| + | |||
| + | ==== Adding A Plugin ==== | ||
| + | First and foremost: please //do not// attempt to add a plugin that you don't " | ||
| + | |||
| + | There are two ways to add a plugin: | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | The first and recommended option is via a GitHub Repository. You'll manage your plugin almost completely through GitHub. You'll create releases there, manage the various descriptions, | ||
| + | |||
| + | The other option is to directly manage everything through our UI. With this approach you'll create your own plugin releases and upload each new release via our plugin administration UI. You'll need to manage all descriptions through our UI. If you don't want to learn how to use GitHub then this is the option for you. | ||
| + | |||
| + | ==== General Rules ==== | ||
| + | First, some general rules that you need to follow regardless of which approach you take: | ||
| + | |||
| + | * Version numbers in the '' | ||
| + | * No two releases can have the same version number (X.Y.Z). | ||
| + | * The Plugin ID (CFBundleIdentifier) can't change once a plugin has been added. | ||
| + | * The Plugin ID **must begin with your developer ID** specified above. This **should not** begin with '' | ||
| + | * If the '' | ||
| + | * Plugins and releases can only be deleted by Indigo Domotics staff. Email us with details if you need a release removed. | ||
| + | |||
| + | ==== GitHub Specifics ==== | ||
| + | If you want to use GitHub (and there are many advantages to doing so), there are a few things to consider. We have a few (but not many) requirements in how your repo is constructed and how you do releases. There are also some optional things that you'll want to consider to make the experience for users even better. | ||
| + | |||
| + | If you're new to GitHub but want to try it out, we've written [[https:// | ||
| + | |||
| + | === GitHub Repo Layout === | ||
| + | This is the required GitHub Repo layout: | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | At the top level of the repo should be your plugin folder and an optional '' | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | Markdown in the '' | ||
| + | |||
| + | === GitHub Releases === | ||
| + | When you are ready to publicly release a version of the plugin (either initially or a follow-up release), you should add a release in GitHub: | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | We **do not** look at the " | ||
| + | |||
| + | == Release Requirements == | ||
| + | There are a few requirements for GitHub releases: | ||
| + | |||
| + | * The GitHub release tag # must match PluginVersion in '' | ||
| + | * The '' | ||
| + | * Although optional, we strongly encourage you to add a zipped version of just the plugin folder (not the entire repo) to each release. Make sure that ' | ||
| + | |||
| + | ==== Adding a Plugin ==== | ||
| + | As we mentioned at the top, there are two ways to add a new plugin to the Plugin Store: by specifying a GitHub repo or by uploading an existing plugin: | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | <color red> | ||
| + | |||
| + | === Adding a Plugin from GitHub === | ||
| + | To add a new plugin from a GitHub repo, just enter the GitHub user and repo names. As an example, for our Rachio Sprinkler repo, which is located here: | ||
| + | |||
| + | '' | ||
| + | |||
| + | We entered **IndigoDomotics** for the user and **rachio-indigo** as the repo. Note your repo must have at least one published release to be added to the Plugin Store. | ||
| + | |||
| + | Click the **'' | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | This form has a variety of fields (some read-only) that fall into two groups. The first group are fields about the plugin itself (not any specific release of the plugin): | ||
| + | |||
| + | - **Plugin ID** - the ID from the '' | ||
| + | - **Name** - the name from the '' | ||
| + | - **Summary*** - a very brief (200 character) summary of your plugin. It is pre-populated with the description for your GitHub repo but you may edit it as you want. It will never be overwritten from GitHub. | ||
| + | - **Description*** - the '' | ||
| + | - **Category** - the major category of your plugin. If you can't find one that seems suitable, then select **Miscellaneous**. This can be changed later. | ||
| + | - **Help URL*** - the help URL pre-populated from the '' | ||
| + | - **Documentation URL** - a separate and optional URL that can point to more comprehensive documentation. This is a good place to put the URL to the GitHub wiki for this repo (see the [[https:// | ||
| + | - **Plugin Icon** - if your plugin' | ||
| + | - **GitHub User and Repo** - a read-only copy of what you entered on the first screen. | ||
| + | |||
| + | And the next section is specific information about the release that you're adding: | ||
| + | |||
| + | - **Release Version** - automatically retrieved from the releases section of GitHub. If you have more than one release in the repo, this will be the most recent (only repos that are not pre-release or draft are used). **Note**: the release version number in the GitHub release source zip's Info.plist **must match** the tag for the GitHub release. Otherwise, the release will not be added. This sanity check will help ensure that you don't end up with version mismatches and the associated problems that will result (failed update checking, failed upgrades, etc). | ||
| + | - **Release Title** - also retrieved from GitHub, it's the short release title. | ||
| + | - **What' | ||
| + | - **Requirements** - an optional separate field that may contain Markdown. The intention of this field is to outline any specific requirements or steps needed to perform for this release. GitHub doesn' | ||
| + | - **Date Released** - the release date as specified in the GitHub release info. You can change it here if you like, using the YYYY-MM-DD format. Note if you change it to some date in the future it won't show up in the Plugin Store until that date. | ||
| + | - **Server API** and **Bundle Versions** - retrieved from the '' | ||
| + | |||
| + | Required fields are marked with an asterisk (*). The majority of GitHub repos will have all the information needed for the required fields so it's only likely that you'll have to edit the Category field as a minimum (and if your plugin is an A/V or IR plugin you won't even have to do that!). Once you have reviewed all the form fields hit '' | ||
| + | |||
| + | You'll notice that on the right side of the screen we've provided a quick cheatsheet for Markdown syntax. This will be helpful when editing any fields that allow Markdown. | ||
| + | |||
| + | === Adding a Directly Managed Plugin === | ||
| + | To add a new plugin from an existing zipped plugin, just click the Choose File button and select the file. Note that Safari will automatically zip plugin folders before uploading (but your browser of choice may not). | ||
| + | |||
| + | Click the **'' | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | This form has a variety of fields (some read-only) that fall into two groups. The first group are fields about the plugin itself (not any specific release of the plugin): | ||
| + | |||
| + | - **Plugin ID** - the ID from the '' | ||
| + | - **Name** - the name from the '' | ||
| + | - **Summary*** - a very brief (200 character) summary of your plugin. | ||
| + | - **Description*** - a full description of what your plugin does. The field may contain Markdown. | ||
| + | - **Category** - the major category of your plugin. If you can't find one that seems suitable, then select **Miscellaneous**. | ||
| + | - **Help URL*** - the help URL pre-populated from the '' | ||
| + | - **Documentation URL** - a separate and optional URL that can point to more comprehensive documentation. So if you have a forum post that contains the documentation for the plugin for instance (and if it's different than the Help URL) then this is the place to put it. | ||
| + | - **Plugin Icon** - if your plugin' | ||
| + | - **GitHub User and Repo** - disabled since this plugin will be managed directly through our pages. | ||
| + | |||
| + | And the next section is specific information about the release that you're adding: | ||
| + | |||
| + | - **Release Version** - automatically retrieved from the '' | ||
| + | - **Release Title*** - a short summary (100 characters max) of this release of the plugin. | ||
| + | - **What' | ||
| + | - **Requirements** - an optional separate field that may contain Markdown. The intention of this field is to outline any specific requirements or steps needed to perform for this release. You may, of course, just add it to the What's New section and leave this field blank. We won't show it if it's blank. | ||
| + | - **Date Released** - the release date defaulting to today. You can change it here if you like, using the YYYY-MM-DD format. Note, if you change it to some date in the future it won't show up in the Plugin Store until that date. | ||
| + | - **Server API** and **Bundle Versions** - retrieved from the '' | ||
| + | |||
| + | Required fields are marked with an asterisk (*). Once you've filled out the form hit '' | ||
| + | |||
| + | You'll notice that on the right side of the screen we've provided a quick cheatsheet for Markdown syntax. This will be helpful when editing any fields that allow Markdown. | ||
| + | |||
| + | ==== Editing a Plugin ==== | ||
| + | To edit a plugin, just go to your Indigo Account' | ||
| + | |||
| + | ==== Adding a Release ==== | ||
| + | When you have an update to a plugin, you just need to add a release to it. Go to the [[http:// | ||
| + | |||
| + | === Adding a GitHub Release === | ||
| + | Adding a GitHub release couldn' | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | The first checkbox is automatically checked and therefore when you Save the form it will add any new releases. The next checkbox will update the main plugin description with the '' | ||
| + | |||
| + | **Note**: the release version number in the GitHub release source zip's Info.plist **must match** the tag for the GitHub release. Otherwise, the release will not be added. This sanity check will help ensure that you don't end up with version mismatches and the associated problems that will result (failed update checking, failed upgrades, etc). | ||
| + | |||
| + | === Adding a Release for a Directly Managed Plugin === | ||
| + | Adding a new release this way isn't really very hard either, there are just a few fields you need to fill out: | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | - **Plugin ZIP File** - click the '' | ||
| + | - '' | ||
| + | - **Release Title*** - a short summary (100 characters max) of this release of the plugin. | ||
| + | - **What' | ||
| + | - **Requirements** - an optional separate field that may contain Markdown. The intention of this field is to outline any specific requirements or steps needed to perform for this release. You may, of course, just add it to the What's New section and leave this field blank. We won't show it if it's blank. | ||
| + | - **Date Released** - the release date defaulting to today. You can change it here if you like, using the YYYY-MM-DD format. Note, if you change it to some date in the future it won't show up in the Plugin Store until that date. | ||
| + | |||
| + | Required fields are marked with an asterisk (*). Once you've filled out the form hit '' | ||
| + | |||
| + | You'll notice that on the right side of the screen we've provided a quick cheatsheet for Markdown syntax. This will be helpful when editing any fields that allow Markdown. | ||
| + | |||
| + | ==== Editing a Release ==== | ||
| + | To edit a release, just go to your plugin' | ||
| + | |||
| + | ==== Icons and Branding ==== | ||
| + | The Plugin Store shows icons for each plugin. If you don't include one in the plugin bundle ('' | ||
| + | |||
| + | To make it easy for users browsing the Plugin Store to identify something they' | ||
| + | |||
| + | * Many companies provide media links, including icons, that can be used for promotional purposes | ||
| + | * Some do it as part of the developer API documentation (often under " | ||
| + | * You can often find logos on their social media accounts in the photograph sections | ||
| + | |||
| + | We believe that the vast majority of companies won't mind you using their logos to promote their products as long as it's clear that you have no direct affiliation to the company. If there is an issue it's easy for us to remove. | ||
| + | |||
| + | Icon details: 256 x 256 is the optimal size. Images **must** be 128px high or they aren't going to look good (somewhat wider might work on some screen sizes). The icons must be .png files and the file name should always be '' | ||
| + | |||
| + | ==== Linking to Indigo Docs ==== | ||
| + | If your documentation needs to link to Indigo' | ||
| + | |||
| + | | ||
| + | |||
| + | and the Indigo 7 docs are at: | ||
| + | |||
| + | https:// | ||
| + | |||
| + | As an example, if Indigo 7.2 had significant enough changes that we decided to create a new namespace then they would be found at: | ||
| + | |||
| + | (https:// | ||
| + | |||
| + | and all references to previous (version 7) doc pages would now point to the old version. In order to help prevent this problem, you can use the following version-agnostic URL instead: | ||
| + | |||
| + | http:// | ||
| + | |||
| + | where PATH_TO_WIKI_DOC is everything after the colon (:) in one of the docs. So, for instance, if you want to link to the sprinkler controls: | ||
| + | |||
| + | | ||
| + | |||
| + | but always want to link to whatever the latest docs are, you could instead use: | ||
| + | |||
| + | | ||
| + | |||
| + | That url will attempt to map that wiki path (and optional anchor) to the most recent doc release. You may, of course, link directly to a specific version namespace doc if that is what is needed. | ||
| + | |||
| + | ==== A Few Final Thoughts ==== | ||
| + | That's pretty much all there is to managing a plugin in the Plugin Store. Here are a few final random thoughts and important reminders: | ||
| + | |||
| + | * Putting your plugin on GitHub will encourage others to help you maintain the plugin. Wouldn' | ||
| + | * We highly recommend that you attach a zipped plugin (don't forget to delete the .pyc files) in your GitHub releases. When users click the Download Release button in the Plugin Store, it will download just the zipped plugin (not the entire repo). It'll be much clearer to users what they need to do next. | ||
| + | * The GitHub wiki page is the best way to provide documentation (see the [[https:// | ||
| + | * The most common way to provide support for a plugin (see //Help URL// above) is via our online forum. You can [[https:// | ||
| + | * You may not delete plugins or releases – if you need to for some reason just let us know and we'll handle it. | ||
| + | * If you want to give someone else edit access (only edit, not add privileges) to your plugins, let us know and we can do that. | ||
| + | * If you need to change a plugin from Directly Managed to GitHub or vice versa, let us know. It's a manually intensive process so it may take us a few days to get everything converted but we will do it for you. | ||