add other plugin sources than the standard repo for auto-update

[zuckung]

Some time ago, I tried to add some of my plugins here, which wasn't possible because I have a multi-plugin repo and the update mechanism couldn't seperate releases of different plugins inside the same repo. I only added the versioning of releases to get them added here :/ Before that, i had a single release with all plugins inside, that just got updated on changes.

My problem is that i created around 30 plugins, maybe half of them i would like to publish here, and i don't want to create 15 repos for that. In my opinion, a multi plugin repo is more elegant. Also auto-update is needed, because i m doing a lot of updates. And you should think of people who create plugins and don't want to go through the long github learning process and prefer simple webspace. I know that you can add plugins from everywhere, but that is without auto-update.

A solution could be, to add the option to identify updates on webspace with last-modified header of the file. Maybe even without versioning. I would appreciate a discussion about that and I hope for a functionality update. Thanks

[tibetiroka]

You can already do that by:

• having different branches for different plugins
• having different zip files created for each plugin

Neither of these is intuitive for people however, so it might be interesting to get some proper support for it in the format.

[zuckung]

I have different zip files for my plugins. Last time i tried to add some here, MCO told me that the update mechanism here can't decide which plugin gets updated on a new release, so it would update all. Maybe you want to take a look at my releases https://github.com/zuckung/endless-sky-plugins.

The oldest release, on the last page has all plugin zips inside, all with latest update, but no versioning. And the normal releases just have a single zip.

[zuckung]

Any news here? Is there an active discussion, or is it delayed to somewhere in the far future?

If there won't be an any near update, i might try the branch solution. But before i restructure my whole repo again i want to get sure that it will work this time.

So creating a plugin free master, and a branch for every plugin, and releases in these branches will definitly work? And there isnt an easier solution?

[tibetiroka]

MCO is rather busy. I'll bring this to his attention when he is more available, but that's likely going to take a couple months.

Maybe I could get some other devs to look at this, but that's going to have to wait until the stable release is out and things calm down a bit.

[tibetiroka]

I haven't tested that branches don't cause the same 'everything updates' issue, but feel free to give it a try.

[MCOfficer]

There's no active discussion besides this issue, but I can give my 2 cents here.

There are two solutions that strike me as possible on your end:

• Stay with your current repository structure and don't use autoupdate. Either PR updates to your plugin manifests manually, or write some kind of automation on your end.
• Use a branch for each plugin, and the "commit" autoupdate instead of "tag". This way you can specify in each manifest what branch should be scanned. The downside is that the manifest will always stay on the bleeding edge, i.e. if you push a new commit, that will be in the plugin repo as soon as possible. Your releases will not be part of the process.

Using the proposed branching solution and releases will not work. when in "tag" mode the autoupdate looks for any tags on your repo, there's no filtering by branch happening.

On the side of the plugin repo, the obvious solution seems to be to introduce a regex that tags are matched against. Others might use this to filter out pre-releases, but in your case you could ask the autoupdate to only look for tags ending in -control.station (or any other plugin name).

[zuckung]

Automating my PRs instead of autoupdate here sounds not too bad. I will think about that. Though not sure if i ll do that.

Maybe waiting is better. Anyway, thx for the answers.

[zuckung]

Any news here? Or any change to motivate someone doing that change?

[MCOfficer]

No news. would need to amend the RFC, then introduce the regex here. And for that I need to find some motivation, which I don't think you can help with.

[zuckung]

Only you can do it! A pure coding virtuoso. I ve checked some of the py scripts and i understand only like a quater of the code. That's godlike! You are the best!

A try worth, asking in a month or two again then.