Indigo Domotics

jay (support) wrote:

We will start thinking about it though and involve our 3rd party developers in the discussion. What we don't want is to get the Github repo construction stuff wrong - that would have some bad repercussions in the future that with a little planning can be avoided.

I'm in the process of taking over as maintainer of an existing plugin, and was wanting to host it on GitHub in the next day or two. I've seen a few different repository layouts there for Indigo plugins and I'd certainly like to emulate those that will best match your plan. Even without a finished plan in hand, is there an existing repository you can recommend that you think might be close enough to mimic now? Feel free to message me if you don't want to suggest something now in this thread.

Check out the Alexa-Hue Bridge plugin - that's pretty close to what we're currently thinking. The most important thing is the releases section. You'll want to make sure that the release tag is the version (i.e. "2.0.7" - though the beta release tag on the 2.0.8 release in there probably isn't right) and that you have a copy of the plugin zipped up and attached to the release (Alexa-Hue.Bridge.indigoPlugin.zip). While not completely settled, this seems like the best way for an automated system (File Library, plugin store, Indigo Server, etc) to get just the plugin (no docs, etc) so we can automatically install it (at some point in the future).

Not final of course, but I think this one is at least pretty close.

Can or has someone written up a "best practices/how to for using github and Indigo? I am new to github and find it painful to get versions updated correctly and how to link the plugin I am working on the the different branches. Seems to be different every time - buts that is probably my lack of understanding.

I have resorted to just doing my development outside of github and just manually uploading new copies of all the files when I have it ready for release.

I like the idea behind GitHub for auto updates of my plugin but don't think I am using it to its full potential.


Sent from my iPhone using Tapatalk

[MODERATOR NOTE] I've split these posts into a separate topic as they were really a tangential (at best) discussion to the original topic they were on.

I'm not sure I'm following your question: above I recommend using one of the current open source repos as a pattern in terms of construction. If that doesn't answer your question, can you be a little more specific in terms of what you're looking for?

I have noticed that some 3rd-party plugins have named their repository as Indigo-XYZ or indigo-XYZ and others as just XYZ. Looking at an old post (viewtopic.php?f=121&t=7434), I see that you don't want us to use your company or product logos/images but it doesn't address the name itself.

So my question is, do you have objections to us naming repos in this way and if you don't, do you have a preference on using "Indigo" versus "indigo"?

I don't see any need to include Indigo in the actual plugin name itself or in the downloadable zip file as that would seem redundant so just XYZ.indigoPlugin and XYZ.zip for those.

I changed all mine to have the "Indigo-" prefix for the repository. I think that just makes more sense, but if Matt/Jay object I can change them...

We are fine with you all using an "Indigo-" prefix on the repo name. Thanks!

matt (support) wrote:

We are fine with you all using an "Indigo-" prefix on the repo name. Thanks!

Good, that should make it easer to find them when searching on GitHub. Thx.


Sent from my iPad using Tapatalk Pro

To guide anyone looking to download my plugin that may found it via a GitHub search, or a search engine that has collected the GitHub page in its trawling I have added this to the top of my README.md source:

Code: Select all

> Because of the volatile nature of individual components within GitHub repositories such as this one, [__please only download actual releases__](../../releases). Any other downloads may result in an incomplete plugin, repeated errors in the Indigo log and/or incorrect behavior of the plugin.


Hopefully this will prevent casual downloads of the repository itself when really what they want is the tested plugin. The embedded link will take them to the releases summary page.